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PREFACE 


This  final  report  presents  the  results  of  work  performed  on  Air  Force  Contract 
F33615-76-C-1215,  Project  No.  2003,  Task  No.  01  (System  Avionic  Architectures  lor  RPVs)  for 
the  Air  Force  Avionics  Laboratory.  The  Air  Force  Program  monitor  was  2dLt.  R.S.  Butler, 
AFAL/AAA. 

The  research  effort  was  conducted  by  Texas  Instruments  Incorporated,  Dallas,  Texas  from 
2 February  1976  to  2 August  1976.  The  final  report  was  submitted  in  February  1977.  Principal 
contributors  to  this  report  were  R.  Allen,  L.  Chamberlin,  J.  Early,  J.  Graham,  W.  Grimes, 
E.  Karintis,  A.  Minnick  and  T.  Shipchandler. 
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SECTION  I 
INTRODUCTION 


This  report  describes  results  of  a 6-niontli  study  to  design  an  avionic  digital  processing 
system  for  the  multimission  Advanced  Remotely  Piloted  Vehicle  (ARPV)  application.  Tlie 
objective  was  to  achieve  a digital  processing  system  providing  not  only  adequate  performance  for 
anticipated  ARPV  missions  but  also  the  lowest  possible  life-cycle  cost  (LCC).  Three  different 
processing  systems  were  designed  to  meet  performance  requirements  for  specific  postulated 
ARPV  missions.  The  total  LCC  for  each  candidate  system  was  then  estimated  using  a postulated 
10-year  life-cycle  scenario.  Tlie  recommended  approach,  selected  on  the  basis  of  minimum  LCC, 
is  a microprocessor-based  design  consisting  of  a distributed  processing  network  with  modular 
processor/memory  elements  (PEs)  interconnected  by  a serial  data  bus. 

The  scope  of  the  program  was  limited  to  system  architectures  utilizing  a single  command/ 
response  time-division  multiplex  data  bus  meeting  the  requirements  of  MlL-STD-1 553A.  Within 
this  scope,  the  general  approach  was  to  design  and  analyze  several  different  systems  representing 
the  most  promising  avionic  processing  concepts  prevalent  today.  Most  of  the  effort  was  directed 
toward  investigating  two  variations  of  a microprocessor-based  distributed  processing  concept  in 
which  separate  homogeneous  processing  elements  are  interconnected  by  a MIL-STD-1  553A  data 
bus.  In  order  to  provide  a common  reference  for  performance  and  LCC  comparisons,  a 
conventional  minicomputer-based  federated  processing  concept  was  also  included  as  part  of  this 
study.  In  the  federated  concept,  a single  central  computer  is  connected  by  a MlL-STD-1 553A 
data  bus  to  a number  of  remote  terminals. 

j As  shown  in  Table  1,  the  three  processing  systems  designed  in  this  study  are  designated  as; 

the  Centralized  system,  the  DP/M  (Distributed  Processor/Memory)  system,  and  the  Hybrid 
system.  The  degree  of  segmentation  or  partitioning  of  the  total  ARPV  processing  problem  is  the 
principal  characteristic  which  differentiates  these  three  systems.  For  the  Centralized  system,  the 
processing  problem  is  not  partitioned  and  all  processing  tasks  are  accomplished  in  one  computer. 
In  the  DP/M  system,  the  problem  is  partitioned  by  task  with  each  major  processing  task  assigned 
to  an  individual  PE.  In  the  Hybrid  system,  which  is  the  approach  recommended  by  this  study, 
the  processing  problem  is  partitioned  by  functional  area  with  groups  of  related  processing  tasks 
I assigned  to  individual  PEs. 

; The  best  utilization  of  microprocessors  or  microprocessor  chip  sets  in  the  ARPV  application 

I was  an  important  consideration  in  this  study.  Current  proliferation  of  microprocessors  and 

related  components  compounds  the  already  complex  and  multifaceted  problem  of  designing  an 
; avionic  processing  system.  In  order  to  achieve  minimum  LCC,  design  of  the  distributed  process- 

* ing  systems  was  based  on  homogeneous  PEs  formed  with  standard  building-block  modules.  The 

‘ use  of  standard  modules  plays  an  important  role  in  achieving  minimum  LCC  both  in  terms  of 

reduced  initial  acquisition  costs  and  reduced  sustaining  costs.  Standard  modules  also  provide 
flexible  system  performance  by  allowing  throughput  capacity  and/or  memory  capacity  to  be 
increased  readily  as  processing  requirements  demand.  Tliis  kind  of  basic  system  flexibility  is 
expected  to  be  particularly  important  as  the  avionic  processing  requirements  change  over  the  life 
of  the  ARPV. 


TABLE  1.  CHARACTERISTICS  OF  CANDIDATE  PROCESSING  SYSTEMS 


System  Parameter 
Weight*  yiounJs) 

Power*  (watts) 

Volume*  (in^) 

Number  of  PEs  or  Remote  Terminals* 

Peak  Throughput  Utilization*  (percent) 

Peak  Memory  Utilization*  (percent) 

Total  System  MTBK  at  4S‘’C*  (hours) 

Mission  Critical  MTBF  at  45“C  (hours) 

Flight  Ciitical  MTBF  at  45°C  (hours) 

Unit  Cost  for  550  System  Buy* 

Relative  LCC 

*1  ach  proceisini!  system  confiyureJ  for  strike  mission 


Processing  System 


Centralized 

DP/M 

Hybrid 

143 

246 

187 

753 

515 

357 

5150 

6700 

4690 

11 

17 

11 

72 

16 

25 

78 

59 

65 

1001 

729 

962 

1 104 

928 

1084 

1485 

1586 

1874 

$105,000 

$89,500 

$63,500 

1.47 

1.28 

1.0 

Hic  standanl  IMt  or  niicrocomptiter  used  in  the  DP/M  system  and  in  the  recommended 
Hybrid  system  is  based  on  an  existing  commercially  available  1^  L 16-bit  microprocessor  chip 
(Texas  Instrtiments  SBP9900).  The  microprocessor  chip  plus  1,536  words  of  nonvolatile  pro- 
grammable read-only  memory  (PROM)  and  1,024  words  of  read/write  random-access  memory 
(RAM)  form  a microprocessor  module  (one  printed  wiring  board)  which  is  the  basic  building 
block  for  the  standard  PH.  This  standard  PF  is  tised  throughout  the  distributed  processing 
networks  with  standard  input/output  modules  and  standard  memory  modules  added  as  required 
for  a particular  processing  task  or  function.  Tliis  standard  module  concept  is  applicable  not  only 
to  the  ARPV  problem  but  other  Air  F'orce  avionic  processing  problems  as  well,  llie  use  of  a 
standard  set  of  modules  across  a wide  range  of  Air  Force  and  other  military  applications  could 
have  a significant  impact  in  terms  of  reducing  total  life-cycle  cost  for  all  the  applications. 

Each  of  the  three  candidate  processing  systems  listed  in  Table  1 was  designed  to  satisfy 
representative  ARPV  processing  requirements  which  were  defined  as  part  of  this  study.  The 
initial  step  in  defining  processing  requirements  was  postulating  scenarios  for  a strike,  a recon- 
naissance (recce),  and  an  electronic  warfare  (EW)  mission  (Appendix  A).  From  the  mission 
scenarios,  a list  of  required  mission  functions  and  generic  equipment  types  was  determined 
(Appendix  B).  Mission  algorithms  were  then  defined  in  terms  of  estimated  throughput,  memory, 
and  data  input/output  requirements  (Appendix  C). 

In  addition  to  meeting  the  actual  processing  requirements,  the  candidate  processing  systems 
also  were  designed  to  meet  mission  reconfiguration  requirements  of  the  multimission  ARPV.  In 
each  of  the  systems,  reconfiguration  of  processing  resources  is  facilitated  by  separating  the 
processing  requirements  into  core  (required  for  all  missions)  and  mission-specific  categories.  For 
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the  DP/M  and  Hybrid  systems,  mission  reconfiguration  is  accomplished  by  removing  unnecessary 
PEs  for  the  bus  network,  adding  required  PEs  and  programming  tlie  mission-specific  part  of  the 
system.  For  the  Centralized  system,  reconfiguration  is  accomplished  by  removing  unnecessary 
remote  terminals  from  the  bus,  adding  required  terminals  and  reprogramming  the  mission-specific 
part  of  tlie  central  computer. 


As  part  of  an  iterative  design  cycle,  the  performance  of  each  candidate  system  was  analyzed 
using  a System  Network  Simulator  (SNS).  The  purpose  of  this  analysis  was  to  determine  loading 
on  the  MlL-STD-1 553A  bus  used  in  each  case.  SNS  results  for  peak  bus  traffic  during  the  strike 
mission  (segment  No.  8)  are  summarized  in  Table  2.  For  all  system  configurations,  worst  case 
loading  of  the  bus  was  found  to  be  approximately  10  percent  or  less  of  the  bus  capacity 
(1  megabit/second). 


TABLE  2.  M1L-STD-1553A  BUS  TRAFFIC  SUMMARY 

M1DSTD-1SS3A 


System 

Peak  Data  Rate 
(kilobits  per  second) 

Peak  Bus  Utilization 
(percent) 

Related  Overhead 
(percent ) 

Centralized 

39.7 

3.97 

37.4 

DP/M 

101.3 

10.13 

48.4 

Hybrid 

93.9 

9.39 

47.0 

In  interpreting  the  results  shown  in  Table  2,  it  is  important  to  note  that  there  are  a number 
of  factors  which  lead  to  higher  bus  traffic  for  the  distributed  systems  as  compared  to  the 
Centralized  system.  For  example,  the  distributed  systems  use  the  network  bus  for  both  transfer 
of  detailed  system  management  information  and  transfer  of  intertask  data.  In  the  Centralized 
system  neither  of  these  types  of  transactions  appear  on  the  bus.  Another  factor  contributing  to 
increased  bus  traffic  is  the  lack  of  a broadcast  mode  in  the  MlL-STD-1 553A  protocol.  Tliis  leads 
to  repetitive  messages  for  the  distributed  systems  which  are  not  required  in  the  Centralized  case. 
Table  2 also  shows  that  bus  traffic  overhead  (command  and  status  words)  is  higlier  for  the 
distributed  systems.  This  is  expected  since  the  bulk  of  the  data  flow  in  the  distributed  networks 
is  associated  with  terminal-to-terminal  transfers  requiring  four  overhead  words  per  message 
according  to  MIL-STD-1 553A  protocol/  The  Centralized  system  on  the  other  hand  is  charac- 
terized by  terminal-to-controller  and  controller-to-terminal  transfers  which  require  only  two 
overhead  words  per  message.  Details  of  the  SNS  computer  runs  are  presented  in  Appendix  D. 


Also,  as  part  of  the  design  cycle,  complete  reliability  and  maintainability  analyses  were 
performed  for  each  candidate  system.  Reliability  factors  (MTBF)  were  estimated  for  each 
configuration  at  assumed  operating  temperatures  of  45°  to  80°C.  MTBF  estimates  for  operation 
at  45°C  are  summarized  in  Table  1 for  total-system,  mission-critical,  and  fliglit-critical  failures.  In 
the  important  area  of  flight-critical  failures,  the  distributed  systems  show  improved  reliability 
over  the  Centralized  system.  This  is  due  to  partitioning  of  the  processing  tasks  and  the  natural 
hardware  redundancy  which  occurs  in  the  distributed  network  approach.  Detailed  results  from 
the  reliability  and  maintainability  analyses  are  presented  in  Section  III  and  Appendix  E of  this 
report. 
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Atk-r  tlic  required  level  of  iierl'oriiKmce  wus  veriricd  for  each  system,  total  IX'C  was 
estimated.  I’liis  estimate  was  made  on  tlie  basis  of  a postulated  ARPV  life-cycle  scenario 
consisting  of  a lO-year  peacetime  period  followed  by  a ,30-day  conllict.  The  LCC  estimates 
include  sottware  and  hardware  costs  for  both  ground-support  ei|uipmc‘nt  and  onboard  ARPV 
pic)cessing  eiiiiipment.  The  l.('C  model  used  in  this  study  and  a listing  of  input  data  for  the 
mode!  are  presented  in  Ap|icndi.\  F and  Appendix  (i,  respectively.  In  addition  to  the  conven- 
tional l.Cr  categories  of  aciiuisition  and  sustaining  costs,  other  factors  were  considered  such  as 
ARPV  attrition  due  to  prcKessor  system  failure. 

LIsing  the  particular  life-cycle  .scenario  dellned  in  this  study,  system  acejuisition  cost  was 
found  to  be  the  dominant  factor  in  total  LCT  for  each  of  the  three  candidate  systems.  Estimated 
accpiisition  cost  for  each  system  is  listed  in  Table  I . Acciuisition  costs  for  individual  components 
in  each  system  are  documented  in  Section  III.  Because  of  necessary  assumptions  made  in  defining 
any  example  life-cycle  scenario,  the  most  meaningful  inter[)retation  of  the  LCC  results  is  to 
compare  systems  on  a relative  basis,  riierefore,  relative  LCC  values  are  shown  in  Table  1.  It 
should  be  noted  that  the  DP/M  and  Hybrid  LCC  estimates  generated  in  this  study  are  for 
homogeneous  processing  systems.  F’or  nonhomogeneous  systems,  it  is  expected  that  LCC'  would 
be  higlier,  primarily  due  to  higher  sustaining  costs. 

Accommodating  future  growth  in  ARPV  processing  reejuirements  is  an  important  factor  in 
evaluating  potential  system  configurations.  The  recommended  Hybrid  system  is  quite  flexible  in 
terms  of  future  growth.  Using  the  most  demanding  processing  requirements  defined  in  this  study 
(strike  mission),  the  Hybrid  system  is  found  to  be  25  percent  loaded  in  terms  of  available 
throughput  and  65  percent  loaded  in  terms  of  available  memory.  Clearly,  there  is  ample  margin 
for  reasonable  growth.  If  future  requirements  exceed  the  available  growth  margin,  additional 
standard  PEs  can  be  added  to  the  existing  network  to  satisfy  essentially  any  practical  require- 
ment. 

Section  II  of  this  report  contains  a discussion  of  general  tradeoff  considerations  regarding 
various  approaches  to  the  ARPV  processing  problem.  Section  III  provides  a detailed  description 
of  the  three  candidate  processing  systems.  A life-cycle  scenario  is  postulated  and  total  cost  of 
ownership  estimated  for  each  candidate  system  in  Section  IV.  Section  \'  contains  a discussion  of 
the  study  conclusions  and  recommendations  for  future  work. 


SECTION  II 

DISCUSSION  OF  THE  ARPV  PROCESSING  PROBLEM 


Tliis  section  describes  general  system  arehiteetures  tor  the  ARPV  processing  application. 
General  software  development  criteria  to  be  used  in  the  ARPV  software  system  design  are 
presented,  including  a discussion  on  the  use  of  High-Order  Language  (MOD  versus  Assembly 
Language  (AL).  The  hardware  considerations  in  implementing  the  ARPV  processing  system  also 
are  discussed. 

The  ARPV  avionic  processing  system  must  satisfy  a number  of  conflicting  requirements.  It 
must  provide  required  multimission  performance  with  minimum  LCC.  It  must  be  reliable  enougii 
to  ensure  a high  probability  of  mission  and  flight  success.  It  also  must  provide  for  the  future 
addition  of  sensors  or  equipment  which  may  us  yet  be  in  the  conceptual  stages.  The  current  state 
of  computer-related  technology  ensures  that  required  ARPV  processing  system  performance  can 
be  achieved.  Tlie  most  difficult  aspect  of  the  problem  is  achieving  a satisfactory  level  of 
performance  with  minimum  LCC.  Minimum  LCC  implies  an  optimum  mix  of  numerous  complex 
system  parameters,  including  system  maintenance  requirements,  support  equipment  costs,  support 
personnel  training  costs,  spares  inventory  requirements,  recurring  acquisition  costs,  and  develop- 
ment costs. 

A.  PROCESSING  SYSTEM  ARCHITECTURES 

Two  basic  processing  system  architectures  are  generally  considered  appropriate  for  the 
ARPV  application;  the  federated  system  and  the  distributed  system.  Both  architectures  are 
compatible  with  the  use  of  a standard  data  bus  concept  (MlL-STD-i  553  A)  which  is  desirable  for 
system  tlexibility  and  future  growth. 

1.  The  Federated  System 

A federated  processing  system  (Figure  1 ) is  defined  as  a computer  system  topology 
consisting  of  shared  information  transfer  paths  and  one  or  more  centrally  located  processors. 
Such  a system  is  generally  characterized  by  one  or  more  high  throughput  computers  connected 
through  a common  data  bus  to  one  or  more  remote  terminals.  The  federated  system,  generally, 
does  not  provide  for  processing  at  a remote  location.  This  architecture  does  provide  a capability 
for  growth  and  a limited  degree  of  functional  redundancy  if  multiple  processors  are  utilized.  In  a 
federated  system  the  processor  or  processors  must  have  sufficient  throughput  to  preprocess  raw 
data  from  the  remote  terminals  in  addition  to  meeting  the  real  time  requirements  of  the  primary 
avionics  algorithms.  The  system  software  also  is  complicated  by  the  general  nature  of  the 
multitask  environment. 

2.  The  Distributed  System 

A distributed  processing  system  (Figure  2)  is  defined  as  a multiprocessor  configuration  with 
shared  information-transfer  paths.  The  distributed  system  differs  from  the  multiprocessor  version 
of  the  federated  system  in  that  individual  processors  have  dedicated  resources  (e.g.,  sensors) 
assigned  which  cannot  communicate  with  the  remainder  of  ihe  system  except  through  the 
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privossor  iIm-’H'.  Althoui>li  a luiinhct  ol'  vanalions  arc  possible,  ilislrihutcd  system  architecture  is 
generalK  cliaracteri/ed  b>  several  lo\v-or  medium-throughput  computers  which  communicate  over 
a common  data  bus.  Modular  microprocessoi/menu)iy  elements  are  ideally  suited  tor  use  in  a 
distributed  system.  The  Dl’/.M  and  Hybrid  configurations  designed  in  this  study  are  examples  ol 
ilistributed  processing  systems. 

file  distributed  architecture  lends  ilsell  to  a modular  approach  in  terms  of  both  hardware 
and  software,  (onseiiuently.  it  is  an  ideal  design  for  those  applications  in  which  a relatively  large 
problem  can  be  partitioned  into  smaller  tasks.  Previous  Air  Force  studies  have  shown  that  avionic 
processing  applications  generally  conform  to  this  reciuirement.*’^  Partitioning  criteria  include 
optimal  resource  allocation,  convenience,  functional  redundancy,  reliability,  data  bus  traffic,  and 
cost  considerations. 

Partitioning  of  the  avionic  processing  requirements  and  the  need  for  reconfiguration  of 
processing  resources  for  different  ARPV  missions  innuences  the  nature  of  the  distributed  system 
software,  l.xecutive  software  for  the  distributed  processing  architecture  can  be  table  driven  and 
thus  relatively  simple  and  flexible.  A table-driven  executive  permits  separation  of  executive  logic 
and  application  logic  modules.  Not  only  can  modifications  and  additions  be  made  to  application 
software  modules,  but  the  capabilities  of  the  executive  can  be  expanded  by  simple  changes  to 
standard  table  data. 

It  is  generally  accepted  that  modularity  in  a complex  system  can  produce  savings  in  a 
number  of  areas  including  development,  production,  and  maintenance  costs.  Tlie  degree  of 
modularity  which  can  be  achieved  in  a distributed  system,  therefore,  can  be  an  important  factor 
in  achieving  a low  LC'C.  Modularity  also  provides  a high  degree  of  flexibility  in  the  distributed 
system  in  that  a wide  range  of  performance  and  redundancy  levels  can  be  easily  achieved. 

B.  GENERAL  SOFTWARE  CONSIDERATIONS 

I.  System  Oriented  Software  Development 

Many  large  processing  systems  have  been  developed  in  an  environment  where  the  hardware 
is  designed  without  careful  consideration  of  possible  software  implications.  The  ARPV  software 
system  design  should  be  accomplished  witli  a design  philosophy  in  which  hardware  and  software 
issues  are  addressed  simultaneously  in  a coordinated  manner.  The  ARPV  operational  environment 
requires  that  the  software  be  reliable  and  easily  maintained.  The  potential  high  cost  associated 
with  software  failure  makes  it  imperative  that  the  software  explicitly  meet  functional  and 
performance  reipiirements.  TIte  certainty  ol  changing  ARPV  missions  and  mission  requirements 
necessitates  a software  structure  which  is  readily  modified.  Tlie  ARPV  software  should  be 
hierarchically  modular  so  that  design  errors  are  discovered  early  in  the  design  cycle  and  many 
error  types  are  prevented  altogether.  Hierarchical  modularity  also  promotes  highly  localized 
error/change  effects  so  that  individual  software  modules  can  be  modified  without  introducing 
errors  or  affecting  other  modules. 

' Kilpalnck.  P.S..  er  a/..  "All  St'iiiicoiidiiclot  iJistribmeil  Aerospace  Processor/Memory  Study.  Volume  1 
AvidiiiiS  Prnccssinn  Requirements,  Honeywell.  Inc.  Contract  No.  F.t361 5-72-C-l 70d,  performed  for  the  Air 
Force  Avimiics  Laboratory.  WPAF'B.  Ohio,  November  1972. 

^Consolver.  G.,  et  at.,  "Distributed  Processor/Memory  Architectures  Design  Program,"  Texas  Instrunrents 
Incorporated.  AFAL-TR-75-80.  performed  for  the  Air  Force  Avionics  Laboratory. 
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Software  Development  Methodology 


I'he  software  development  inetliodology  should  assist  in  accomplishing  the  following  tasks: 
Receive  system  re(|uirements  and  analyze  them  to  produce  a software  design. 

Implement  the  design  in  analytic  code.  Iliis  usually  is  accomplished  by  several  differ- 
ent programmers. 

Integrate  the  modules  of  code  together  to  form  a test  process  which  is  then  evaluated 
for  deficiency  of  logic,  data  How  and  performance.  Corrections  arc  made  by 
returning  to  appropriate  steps  in  the  above  cycle. 

One  of  the  most  important  aspects  of  the  overall  effort  is  a clear  and  testable  set  of 
requirements.  These  requirements  should  be  unambiguous  and  should  be  used  as  a guide 
throughout  the  software  design,  implementation  and  operational  stages.  At  the  requirements 
level,  it  is  often  observed  that  requirements  are  ambiguous  in  that  they  do  not  mean  the  same 
thing  to  the  system  designer  and  the  software  designers/programmers.  Furthermore,  during  the 
long  software  development  cycle  and  on  into  the  operational  phases,  requirements  change;  some 
due  to  a better  understanding  of  the  nature  of  the  process  and  some  due  to  changes  in 
application  or  mission  requirements.  It  is  clear  that  a software  development  methodology  must 
readily  accommodate  changing  requirements. 

The  processing  requirements  should  then  be  partitioned  into  tasks.  Traceability  of  individual 
tasks  to  the  original  requirements  is  important.  During  top-level  design,  a model  of  each  task 
should  be  tested  in  a system  network  simulator  in  order  to  make  efficient  processor  assignments 
and  test  the  interrelationships  among  tasks  so  assigned.  At  this  stage,  task  sequencing  control  and 
scheduling  schemes  should  be  tested  to  make  sure  that  a suitable  amount  of  computer  capability 
has  been  allocated  and  that  no  task  will  create  a bottleneck  in  the  system.  The  tasks  themselves 
should  then  be  carried  through  an  evolutionary  design  process  in  which  they  are  refined  using  a 
top-down  design  approach.  Each  task  should  be  tested  against  the  system  simulator  at  every  stage 
of  this  successive  refinement.  The  resulting  modular  structure  should  be  maintained  so  that  there 
is  the  utmost  simplicity  in  the  final  structure  itself.  At  each  stage  of  refinement,  a firm  interface 
specification  should  be  documented  before  any  coding  of  the  module  begins.  At  the  end  of  this 
evolutionary  design,  since  testing  has  occurred  at  all  stages  and  since  every  interface  has  been 
“designed”,  the  software  should,  in  fact,  be  operational  with  no  need  for  integration  in  the 
standard  sense. 

3.  System  Simulator 

Throughout  the  design  process  described  above,  there  exists  a need  for  a system  simulator. 
The  typical  system  simulator  should  consist  of  an  integrated  set  of  tools  which  aids  the  system 
designer  at  every  stage  of  the  process.  Four  basic  model  types  can  be  used  to  represent  software 
components  in  simulators: 

Computer-independent  models 
Synthetic  models 
Functional  models 
Analytic  models. 


Computer  independent  models  describe  program  execution  dynamics  by  specilying  counts 
of  various  operations,  memory  requirements,  program  input/outputs  and  subroutine  calls  and 
alternative  program  execution  paths. 

Synthetic  models  of  programs  are  produced  by  merging  the  characteristics  of  the  computer 
under  consideration  with  the  computer-independent  model  of  the  program. 

TTie  functional  model  of  a program  includes  the  synthetic  model  and  the  functional  model 
of  the  computational  procedure  which  is  to  be  represented  by  the  program. 

The  analytic  model  is  the  actual  implementation  of  a program  or  task  on  the  target 
configuration.  Figure  3 summarizes  the  evolution  of  models  and  shows  their  temporal  ordering 
during  software  development.  Figure  4 shows  the  relationship  between  the  hierarchical  levels  of 
simulators. 

4.  Executive  Software 

The  use  of  distributed  processing  elements  or  remote  terminals  in  the  ARPV  processing 
system  dictates  the  need  for  a method  of  scheduling  activities,  transferring  bus  messages  between 
elements  on  the  bus  and  general  system  control.  These  operations  are  referred  to  as  executive 
functions.  The  executive  requirements  for  a multitask  federated  processing  system  are  well 
known  and  will  not  be  repeated  here.  This  section  will  deal  only  with  the  executive  requirements 
for  a distributed  processing  network. 

The  role  of  the  executive  software  within  the  context  of  the  distributed  system  concept  is 
to  provide  a set  of  basic  control  functions  necessary  to  schedule  avionic  mission  software 
routines  and  provide  a common  communication  mechanism  for  inter-PE  data  transfers.  Ideally, 
the  executive  should  impose  minimum  computational  overhead  on  the  hardware  resources  while 
providing  minimum  but  necessary  control  operations  to  ensure  satisfactory  performance  of  the 
PE  network  in  accomplishing  avionic  processing  in  a timely  manner.  The  distributed  system 
executive  must  operate  within  the  capabilities  (and  adhere  to  the  restrictions)  of  the  system 
hardware  resources  and  the  modes  of  the  likely  avionic  system  operation  within  a mission.  In 
addition,  the  structure  or  organization  of  real-time  avionic  programs  dictates  that  the  executive 
provide  the  necessary  means  of  scheduling,  monitoring,  and  providing  data  set  management 
between  cooperating  processing  tasks. 

The  physical  separation  of  PEs  in  a network  requires  that  the  executive  provide  a timely 
method  of  transmitting  data  between  PEs.  Tlie  need  to  reconfigure  processing  resources  for  the 
multimission  ARPV  imposes  the  requirement  that  the  executive  structure  be  adaptable  to  various 
topological  interconnections  with  minimum  modifications  and  maximum  expectation  that  newly 
created  control  software  will  function  properly. 

5.  Software  Language— HOL  Versus  AL 

Developers  have  been  cautious  and  reluctant  to  utilize  a HOL  rather  than  AL  to  implement 
avionics  software  because  of  apparent  investment  costs,  programmer  retraining,  and  reduction  in 
computer  memory  efficiency.  Benefits  of  HOL  are  not  as  obvious  as  these  costs,  and  developers 
are  unwilling  to  risk  such  a major  departure  from  established  practices. 
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Figure  3.  Evolution  of  Process  Models 


Hie  real  value  ot  HOL  systems  lies  in  sueli  factors  as  testability,  hardware  independence, 
programming  flexibility,  operational  reliability,  maintainability  and  lower  development  risk 
associated  with  software  hatidover  to  new  programmers,  reduced  training  problems,  software 
commonality,  etc.  Ihese  characteristics  are  relatively  difficult  to  evaluate  or  compare  in  terms  of 
dollar  costs,  for  example,  the  assumption  of  few  software  changes  would  favor  AL,  while  the 
assumption  of  many  changes  would  favor  HOL.  How  many  software  changes  there  actually  will 
be  over  the  life  of  a system  depends  nut  only  on  how  well  the  system  has  been  designed  to 
satisfy  operational  reiiuirements,  but  also  on  how  fixed  the  requirements  are,  and  on  how  readily 
the  software  may  be  safely  changed. 
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An  increasing  amount  of  avionics  software  is  now  being  written  in  HOL  such  as 
JOVIAL,  J3B,  a dialect  ot  JOVIAL,  the  Air  Force’s  command  and  control  programming  language. 
Based  on  comparison  ol  typical  computer  output  with  functionally  equivalent,  hand-coded 
assembly  language  programs,  it  has  been  determined  that  a compiler  can  provide  a machine  code 
which  is  within  10  1 5 percent  of  the  memory  and  execution  time  bounds  established  by 
hand-coded  programs.  In  most  cases  for  the  ARPV  application,  the  efficiency  of  computer- 
generated code  is  expected  to  be  sufficient  to  satisfy  overall  system  constraints.  Where  memory 
and  execution  time  are  critical,  a program  can  be  fine  tuned  by  coding  in  assembly  language. 

A MOL,  such  as  JOVIAL,  lends  itself  to  structured  programming  and  thus  has  the  added 
benefit  t)l  being  self-documenting.  Out-of-date  software  documentation  is  a major  problem  in 
many  applications.  Because  of  the  small  amount  of  detail  (value  of  pages,  variables,  switches, 
etc.)  necessary  for  the  programmer  to  understand  and  retain  to  make  a change,  a structured  HOL 
can  be  very  cost  effective  in  the  operational  phases. 

Untortunately,  it  is  not  practical  to  separate  the  effects  of  HOL  from  other  computer 
parameters  and  no  irrefutable  conclusions  can  be  drawn.  However,  the  use  of  HOL  in  recent 
avionics  applications  has  shown  that  HOL  is  practical,  even  in  real-time  systems,  and  carries  a 
number  of  benefits.  It  has  also  been  shown  that  the  computer  instruction  repertoire  affects 
efficiency  more  than  HOL.  In  this  respect,  the  only  added  cost  of  HOL  would  seem  to  be  in 
added  memory  space.  However,  the  continuing  downward  trend  for  memory  costs  while  software 
costs  rise,  makes  the  relatively  small  decrease  in  efficient  use  of  memory  insignificant. 

Some  typical  differences  between  HOL  and  AL  can  be  summarized  as  follows; 

Cost  Comparison 
HOL  Versus  AL 

Same 
Same 

5 percent  savings 
20  percent  savings 

At  this  time  there  is  no  firm  answer  to  the  HOL  versus  AL  tradeoff.  All  of  the  various 
factors  still  need  to  be  considered  individually  for  each  application  considered.  The  size  of  the 
hardw'are  buy,  the  type  and  cost  of  memories  involved,  complexity  of  the  functions  being 
executed  in  software,  overall  system  complexity,  and  customer  requirements  are  a few  of  the 
variables  which  must  be  considered. 

C.  GENERAL  HARDWARE  CONSIDERATIONS 

This  section  deals  with  i|uestions  of  hardware  standardization  and  selection  of 
microprocessor  type  for  the  distributed  processing  approach  to  the  ARPV  application. 

I.  Standard  Modules 

The  ARPV  avionic  processing  tasks  span  the  spectrum  from  simple  programmable 
controllers  to  high  throughput  applications.  This  overall  problem  can  be  solved  in  a number  of 
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ways  including  the  mixed  use  of  bit  slices,  4-bit,  8-bit  and/or  16-bit  microprocessors  in  a 
distributed  processing  network.  The  advantages  of  a standard  module  approach  are  presented 
below. 

In  many  past  avionics  applications,  standardization  of  hardware  has  not  been  widely 
practiced.  This  situation  cannot  be  totally  criticized,  for  the  state-of-the-art  in  computer  systems 
in  the  past  has  not  been  sufficiently  stable  to  permit  standardization  without  significant 
performance  penalty.  In  the  past  few  years  the  state-of-the-art  has  stabilized  to  a degree,  and 
previous  experience  has  provided  the  historical  lessons  and  insight  required  to  develop  meaningful 
guidelines  for  standardization  on  a family  concept. 

There  are  several  factors  which  now  suggest  standardization  on  a single  family  of  processors 
for  a broad  range  of  applications.  First,  computer  architecture  has  stabilized  sufficiently  so  that 
computer  system  performance  is  now  more  a function  of  specific  implementation.  Further,  the 
realization  has  come  and  is  supported  at  all  levels  of  Government  and  industry  that  the  total 
LCC  of  a computer  system  is  often  more  a function  of  software  and  logistic  costs  than  it  is  of 
original  hardware  acquisition  cost.  Also  there  is  a continuing  trend  throughout  industry  toward 
standardization  of  both  hardware  and  software.  This  approach  permits  sharing  a common  support 
software  base  and  common  hardware  subsystems  and  modules  across  family  lines.  An  example  is 
the  Texas  Instruments  family  of  16-bit  microprocessors  (9900  series).  Rather  than  develop 
unique  architectures  for  the  MOS  (TMS  9900)  and  the  I^L  (SBP9900)  implementation 
technologies,  the  architecture  of  an  existing  commercial  16-bit  minicomputer  (Texas 
Instruments  990)  was  used.  The  above  factors,  coupled  with  the  continuing  reduction  of 
hardware  costs,  suggests  the  use  of  a family  of  relatively  few  machine  classes  for  a broad  range 
of  processing  applications. 

I Current  information  indicates  that  the  cost  of  various  size  microprocessors  will  not  vary 

significantly  once  a given  device  is  mature  and  widely  used.  Thus,  there  is  little  to  be  gained  in 
terms  of  reduced  acquisition  cost  by  mixing  different  size  microprocessors  in  an  avionic 
application.  By  far  the  dominant  consideration  is  the  effect  on  sustaining  cost.  A nonhomoge- 
neous  processing  system,  using  several  different  types  or  sizes  of  microprocessors,  will  complicate 
the  logistics  problem,  thereby  increasing  overall  system  LCC.  The  most  cost-effective  approach 
■ appears  to  be  a homogeneous  system  in  which  a standard  size  and  type  microprocessor  is 

selected  which  best  satisfies  overall  requirements  of  the  particular  application.  This  standard 
1 choice  should  then  be  used  throughout  the  distributed  network  for  the  individual  partitioned 

tasks  or  functions  within  the  avionic  application. 

; 2.  Microprocessor  Size 

• The  foregoing  discussion  on  standardization  argues  against  mixing  different  size 

•.  , microprocessors  in  a typical  avionics  application.  There  are  several  factors  to  be  considered  in 

selecting  the  microprocessor  size  to  be  used  as  the  standard  processing  element. 

There  exists  in  the  typical  avionics  application  some  tasks  where  large  blocks  of  data  must 
be  processed,  or  where  speed  and  high  resolution  are  needed.  In  such  processing  tasks,  an  8-bit 
word  length  or  less  can  be  a serious  handicap.  A 16-bit  micropiocessor  can  reach  external 
memory  locations  2 bytes  at  a time  and  the  longer  length  (16-bit)  data  words  can  easily 
accommodate  8-,  12-,  14-,  and  16-bit  converter  resolutions. 


I 
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TABLE  .V  PERFORMANCE  OF  Ifr-BIT  MICROPROCESSOR  VERSUS  8-BIT  MICROPROCESSORS 


1 


Bus  interlace  coiisitlerations  also  oiitor  into  llu'  sck’ction  ol'  microprocossor  size.  A tspital 
iiK'ssagi'  transfer  on  a Ml L-S'I'D- 1 553A  hus  consists  ol  a commaiKl  word,  one  or  more  data 
words,  and  a status  word.  The  data  information  content  of  each  ol  these  woni  types  is  Iti-hit'. 
Therefore,  a simplification  in  design  comple.\ity  will  result  if  the  interlace  with  MIL-.S'I  ))-l  .‘'5.vA 
protocol  is  designed  for  a Ih-hit  microprocessor  rather  than  an  H-hit  or  other  alternative. 

The  basic  performance  advantage  of  a lb-hit  microprocessor  (wer  smaller  machines  can  he 
demonstrated  quantitatively.  Benchmark  tests,  comparing  the  lb-hit  SBl’ d900  with  the  popular 
8-bit  8080,  and  the  8-bit  6800  microprocessors  are  summarized  in  Table  3.  .Six  tests  are  shown 
with  comparisons  made  in  program  memory  requirements,  lines  of  assembler  code  and  execution 
times.  Results  for  the  separate  test  programs  are  summed  together,  showing  that  the  Ib-hit 
imcroproces.sor  saves  an  average  of  at  least  20  percent  on  program  memory,  with  .38  percent 
fewer  assembler  statements,  and  an  average  execution  time  at  least  42  percent  faster. 

The  need  for  tloating-point  operations  in  some  avionic  processing  tasks  also  affects  the 
choice  of  microprocessor  size.  If  floating-point  algorithms  are  implented  in  software,  a ib-bii 
microprocessor  has  definite  execution  time  advantages  over  an  8-bit  machine,  lor  typical 
tloating-point  operations,  the  execution  time  for  an  8-bit  machine  is  2 to  4 times  that  ot' a Ib-hii 
machine.  If  a hardware  tloating-point  arithmetic  unit  is  used,  there  are  no  signillcant  dilTerence-. 
in  the  performance  of  a lb-bit  versus  an  8-bit  machine. 

Figure  3 shows  the  relative  costs  for  a Ib-hit  processing  system  versus  an  8-bit  system,  l or 
large  configurations,  although  Cl’LI  costs  may  be  higher  for  the  lb-bit  than  for  the  8-hii 
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ml^.rop|■o^.^.■^sol,  the  ovcnill  lO-bit  system  costs  considerably  less  due  to  the  elTieiency  with  which 
It  handles  large  amounts  of  memory,  I/O  and  interrupts. 


l or  purposes  of  ihis  sliuly,  the  SBP  9^00  is  selected  as  a representative  16-bit  standard 
microprocessor  tor  use  in  the  ARl’V  distributed  processing  networks.  Standard  processor, 
memory  and  I O modules  have  been  designed  around  the  SBP  9900.  Processing  elements  formed 
troni  these  modides  can  perform  many  avionic  processing  tasks  from  simple  sensor/actuator 
controllers  to  sophisticated  high-precision,  high-throughput  applications.  In  addition,  the 
SBP  9000  IS  a member  of  a family  of  compatible  products  (for  commercial  and  military 
computei  system  applications)  which  are  supported  by  a common  software  system  including 
llOL  compilers. 

d.  Bit  Slice  Processing  Element 

1 he  Use  of  bipolar  bit  slice  processing  elements  is  a possible  approach  for  the  ARPV 
avionics  processing  application.  Two  important  advantages  of  the  bit  slice  technique  are: 

High  throughput  capacity  which  can  be  achieved  in  a modular  building-block  fashion, 
and 

Ability  to  emulate  a wide  variety  of  processor  types. 

Piocessoi  emulation  may  be  a particularly  significant  feature  for  government  applications  where 
standardi/ing  on  a single  instruction  set  or  microprocessor  type  may  not  be  feasible. 

Although  advantages  of  the  bit  slice  technique  are  important,  this  approach  does  lead  to 
increased  LCC.  Unlike  a microprocessor,  a bit  slice  processing  element  is  only  a section  of  a 
central  processing  unit  (('PUl.  For  e.xample,  a 16-bit  microcomputer  design  requires  four  4-bit 
slices  for  the  CPU  plus  numerous  other  peripheral  circuits  for  I/O  functions.  Because  of  the 
higher  LCC,  the  bit  slice  approach  was  not  considered  for  use  in  distributed  processing  networks 
in  this  study. 


Bit  slice  processing  elements  also  could  be  used  to  form  a very  powerful  low-cost  CPU  for 
use  m a centralized  architecture.  Although  this  is  probably  technically  feasible,  it  is  not 
considered  to  be  a practical  approach  because  of  the  many  advantages  offered  by  distributed 
processing  architectures  and  the  current  strong  trend  toward  such  architectures  in  both  industry 
and  government. 


SECTION  III 

DESCRIPTION  OF  THREE  CANDIDATE  SYSTEMS 


A.  INTRODUCTION 

In  order  to  design  specific  candidate  processing  systems  it  was  necessary  to  first  define 
representative  ARPV  mission  scenarios  and  associated  processing  requirements.  Scenarios  were 
defined  for  a strike,  a recce,  and  an  EW  mission.  These  scenarios  and  required  mission  functions 
are  summarized  in  Appendix  A of  this  report.  A list  of  the  core  and  mission-dependent 
equipment  required  to  support  the  ARPV  missions  is  shown  in  Appendix  B.  For  purposes  of  this 
study  only  generic  equipment  types  were  considered.  An  equipment  signal  list  also  is  included  in 
Appendix  B. 

Algorithms  required  to  support  the  ARPV  missions  are  shown  in  Appendix  C.  Estimates  of 
tile  processing  requirements  necessary  to  execute  these  algorithms  form  the  basis  for  the  design 
of  each  candidate  ARPV  processing  system. 

Functional  diagrams  for  core  and  mission-specific  avionics  are  shown  in  Figure  6 through 
Figure  9.  These  diagrams  illustrate  the  functional  relationship  between  ARPV  equipment 
(rectangular  blocks)  and  algorithms  (square  blocks). 

The  scope  of  t'us  program  was  limited  to  investigating  processing  system  architectures  which 
utilize  a single  command/response  time-division  multiplex  data  bus  meeting  the  requirements  of 
MIL- STD-1  553A.  The  advantages  of  this  standardized  bus  approach  for  avionic  applications  are 
documented  in  contemporary  studies  and  are  not  repeated  here.  Within  this  scope,  three 
different  processing  systems  were  designed  to  meet  the  functional  requirements  shown  in 
Figure  6 through  Figure  9: 

Cientralized  System 
DP/M  System 
Hybrid  System. 

The  Centralized  system  consists  of  a single  central  computer  connected  by  a 
MIL-STD-1 553  A data  bus  to  a number  of  remote  terminals.  Tliis  type  of  processing  architecture 
was  included  in  this  study  primarily  to  provide  a reference  for  performance  and  LCC 
comparisons. 

Most  of  the  program  effort  was  concentrated  on  two  versions  of  a distributed  processing 
approach  to  the  ARPV  processing  problem.  In  the  distributed  processing  approach,  separate 
processing  elements  are  interconnected  by  a MIL-STD-1 553A  data  bus.  Tlie  two  distributed 
networks  considered  in  this  study  are  both  homogeneous  processing  systems  and  differ  only  in 
the  degree  of  partitioning  of  the  total  ARPV  processing  problem  In  the  DP/M  system,  the 
problem  is  partitioned  by  major  task  while  it  is  partitioned  by  functional  area  in  the  Hybrid 
system. 

Reconfiguration  of  processing  resources  for  specific  missions  was  a basic  design  requirement 
for  each  candidate  system.  In  all  cases,  reconfiguration  is  facilitated  by  the  use  of  a standard 
data  bus  and  by  separating  the  processing  system  resources  into  core  and  mission-specific 
categories. 
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Bus  loatlini:  loi  cacli  caiuliilati.'  system  was  analyzed  iisiiif!  a modilled  version  ol  the  Ssstein 
Network  Simulator  (SNS)  developed  under  Al'AL  C'ontrael  1-3361  S-74-('-101  K.  SNS  results  are 
summarized  In  this  seetion  of  the  report  as  part  of  the  tleseri|Uion  of  eaeh  eandiilate  system. 
Additional  detail  on  the  SNS  work  is  meluded  as  .Appendix  I). 

1.  Proeessing  Requirements 

i'rom  the  material  presented  m Appendix  A through  Appendix  C the  speeifie  algorithms 
reipiired  during  individual  mission  segments  can  he  determined,  fable  4 through  table  6 show 
this  information  in  a time-lme  analysis  formal  for  eaeh  mission. 

Memory  and  throughput  estimates  for  individual  algorithms  are  shown  in  Table  1.* 
IndiviLlual  algorithm  throughput  requiremen  j,  together  with  the  previous  eharls  showing 
algorithm  aetivit>  in  eaeh  mission  segment,  ean  be  used  to  determine  the  total  proeessing 
throughput  requirement  for  eaeh  mission  segment  as  shown  in  fable  8 through  Table  10.  Total 
memory  reiiuirements  are  shown  m Table  1 I. 


*Tlic  algoriihm  esiiinates  are  intciKleci  lo  he  representative  requirements  established  for  syslem  de.dgn  purposes 
only.  These  estimates  should  not  be  interpreted  as  liim  specifications  for  the  ARI’V  application. 


18 


Figure  6.  Core  Avionics  Functional  Diagram 


RADIATION 


Figure  7.  Strike  Mission  Avionics  Functional  Diagram 


Figure  8.  Recce  Mission  Avionics  Functional  Diagram 


TABLE  5.  RECCE  MISSION  TIME-LINE  ANALYSIS 


l AHI  K 7 A1.GOKI  IHM  PROC  ESSING  REQUIREMENTS 


Moinory  (16-Bit  Words) 


Tliroughpul 


Algorillim 

Instructions 

Data 

Total 

(KOPS) 

C ori* 

1 \S  ( sli  jpiliUMi  1 

T.OOO 

500 

3.500 

65 

N,u  lu.iliiiii  1 ilU'i 

1 ,300 

2,300 

3.600 

35 

t.l'S 

1 1.500 

2.100 

13,600 

68 

Sii'omii; 

720 

50 

770 

1 1.5 

riiplit  ('iinlu)l 

2.750 

600 

3,350 

45 

Air  Uala 

5()0 

75 

635 

6 

KaJar  Allmii'lei  Siibsyslciii  Scivko 

150 

30 

180 

0,5 

Mismoii  ( \>ntiol 

3,300 

2,000 

5,300 

15 

( iiiklance 

2,200 

300 

2,500 

7 

Ml  S 

(i60 

100 

760 

7.5 

Status  Mmutui 

550 

500 

1,050 

3 

\airouhaikl  Data  link 
SiibsystiMii  Seivk'i' 

550 

500 

1 ,050 

3 

IN'  Siihsy stem  Soivlee 

150 

50 

170 

0.5 

Bus  Control 

1,000 

2,000 

3,000 

30 

Bulk  Storage  Subsystem  Service 

50 

20 

70 

0.5 

j Aiieiatt  InsliiimeiiMtion  Siihsysteitt  Service 

70 

30 

100 

0.5 

Mission  Specific 

i Line-ot-Siglil  ( omputation 

330 

50 

380 

5 

1 inget  I’l'silioii  Compulation 

330 

50 

380 

5 

Impact  I’oitil  Compulation 

1,760 

200 

1 ,460 

71 

IT  IK  Subsystem  Service 

600 

100 

700 

3 

Kadialion  Sensoi  Subsystem  Service 

600 

100 

700 

2 

IT  KCOM 

2,450 

2,000 

4,450 

70 

J 

1 Wideband  Data  lank  Subsystem  Seivice 

170 

50 

220 

0.5 

j Weapon  Station  Subsystem  Service 

550 

100 

650 

3 

!R  Lane  Scanner  Subsystem  Service 

220 

50 

270 

1 

Photo  I'amera  Subsystem  Service 

220 

50 

270 

I 

' ( lialT  Dispenser  Subsystem  Service 

330 

60 

390 

1 

riireal  Warning  Receiver  Subsystem  Service 

400 

100 

500 

1.5 

Active  Jammer  Control 

880 

200 

1,080 

7 

Throughput  Per  Segment  (KOfS) 


TABLE  II.  TOTAL  ALGORITHM  MEMORY  REQUIREMENTS 


Memory  (16-Bit  Words) 


Mission 

Core  Functions 

Mission-Dependent  Functions 

Total 

Strike 

39,635 

9,440 

49,075 

Recce 

39,635 

5,210 

44,845 

IW 

39,635 

1,970 

41,605 

2.  Modular  Processing  Element 

The  following  standard  modules  are  used  to  form  PEs  for  both  the  DP/M  and  Hybrid 
distributed  processing  systems; 

Microprocessor  Module  (MPM) 

Program  Memory  Module  (PMM) 

Data  Memory  Module  (DMM) 

Serial  Bus  Interface  Module  (SBIM) 

I/O  Interface  Module  (lOIM) 

Voltage  Regulator  Module  (VRM). 

The  functional  organization  of  modules  within  a PE  is  shown  in  Figure  10.  The  physical 
characteristics  of  individual  modules  are  shown  in  Table  12. 

TABLE  12.  PROCESSING  ELEMENT  MODULE  CHARACTERISTICS 


Module 

Weight 

(pounds) 

Power 

(watts) 

Width 

(inches) 

Length 

(inches) 

Height 

(inches) 

MPM  (rme  PWB) 

0.5 

4.75 

0.58 

5.62 

4.8 

SBIM  (Digital  one  PWB) 

0.5 

5.19 

0.58 

5.62 

4.8 

(Analog  - one  PWB) 

0.5 

5.76 

0.58 

5.62 

4.8 

lOlM  (one  PWB) 

0.5 

2.3 

0.58 

5.62 

4.8 

PMM  (one  PWB) 

0.5 

2.5 

0.58 

5.62 

4.8 

DMM  (one  PWB) 

0.5 

3.3 

0.58 

5.62 

4.8 

VRM  (one  PWB) 

1.5 

* 

0.58 

5.62 

4.8 

Connector  Board 

1.32 

NA 

2.25 

19.56 

NA 

Long  Quarter  ATR 

2.5 

NA 

2.25 

19.56 

7.62 

PWB  Guides 

1.6 

NA 

0.5 

0.5 

4.8 

Mounting  ilaidwate 

*• 

NA 

NA 

NA 

NA 

•50  percent  of  total  PI  power 
**I0  percent  of  total  PI.  weight 
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Figure  10.  Processing  Element  Functional  Organization 


V 


r 

! 


A 


. I 


I 


i 

I 


TABLE  13.  MPM  CHARACTERISTICS  (SBP  9900) 


lypc 

Nmiihei  syslom 

DatLi  wokI  length 

Instruetioii  woui  length 

Mcniory 

MPM  capacity 
PROM* 

R.AM** 

Register  complement 


Instruction  repertoire 

Instruction  e.xecntion  times 
Add 
Multiply 

Inpnt/Ontput 


Interrupts 

Physical  characteristics 
Si/e 
Weight 
Power 

Cost 

*Si.\  chips  (512  X 8 hits) 
**i-ivc  chips  (1024  X 4 hits) 


Parallel 

Binary,  2’s  complement 
It)  bits  including  sign 
16  bits 

Addiessable  to  32K 

1 536  16-bit  words 
1024  16-bit  words 

16  general  registers  per  program  context  located  in 
memory 

3 user  accessible  internal  registers: 

16-bit  program  counter 
16-bit  status  register 
16-bit  workspace  pointer 

69  basic  instructions 


3.5  /as 
13  /as 

16-bit  parallel  I/O  addressable  as  memory. 

Bit  serial  I/O  with  4096  directly  addressable  input 
bits  and  4096  directly  addressable  output  bits. 

16  prioritized  interrupts 


0.58  width  X 5.62  length  X 4.8  height  (inches) 
0.5  pound 
500  mW 

SI  163  in  quantities  of  5,000 


Tor  purposes  of  this  study,  tlie  16-bit  PL  SBP  9900  microprocessor  was  selected  for  use  in 
the  standard  MPM.  The  characteristics  of  the  MPM  are  listed  in  Table  13.  For  an  instruction  mix 
of  80  percent  short  (3.5  /as)  and  20  percent  long  (13  ^ls),  the  throughput  capacity  of  the  MPM  is 
185  kilo  operations  per  second  (KOPS). 

In  addition  to  an  MPM,  a basic  PE  contains  an  SBIM,  an  lOlM,  and  a VRM.  Tlie  SBIM 
provides  for  interface  to  the  network  data  bus  in  accordance  with  the  requirements  of  MIL-STD- 
1553A.  The  lOIM  provides  for  interface  to  external  ARPV  sensors  or  subsystems.  Up  to  seven 
separate  sensors  or  subsystems  can  be  accommodated.  The  VRM  provides  for  interface  to  a 
central  power  supply  subsystem. 


For  processing  tasks  requiring  more  memory  than  provided  in  the  basic  PE,  memory  can  be 
expanded  by  adding  PMMs  or  DMMs  as  required.  A single  PMM  provides  4096  words  of 
nonvolatile  programmable  read-only  memory  (PROM).  A single  DMM  provides  4096  words  of 
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read/write  random-access  memory  (RAM).  In 
addition  to  the  four  basic  modules,  a fully 
expanded  PE  contains  four  memory  modules 
(any  mix  of  PMMs  and  DMMs).  TJie 
characteristics  of  a basic  PE  and  a fully 
expanded  PE  are  summarized  in  Table  14. 

Both  the  DP/M  and  Hybrid  processing 
networks  interface  with  the  aircraft  prime 
power  source  through  a power  supply 
subsystem  as  shown  in  Figure  1 1 . The  power 
supply  subsystem  consists  of  two  power 
supply  modules,  each  providing  five  separate 
power  output  channels.  Each  output  channel  provides  the  power  requirements  for  up  to  three 
fully  expanded  PEs  (150  watts  maximum).  The  power  supply  subsystem  includes  an  auxiliary 
battery  pack  capable  of  providing  1 .5  kVX  (30  volts  at  50  amperes)  for  a minimum  period  of 
10  seconds.  The  battery  pack  is  included  in  order  to  sustain  PE  power  during  possible  transient 
periods  as  required  by  MIL-STD-704A.  All  PEs,  power  supply  modules,  and  the  auxiliary  battery 
pack  are  contained  in  Long  Quarter  ATR  cases  (7.625  inches  X 2.25  inches  X 19.562  inches). 
Battery  pack  weight  is  approximately  30  pounds;  each  power  supply  module  weighs  approxi- 
mately 20  pounds. 

An  example  of  the  PE  task-assignment  procedure  used  in  this  study  is  provided  here  to 
illustrate  how  memory  and  throughput  loading  are  determined.  Assume  that  the  INS  (strapdown) 


TABLE  14.  PE  CHARACTERISTICS 


Basic  PE 

Fully  Expanded  PE 

Volume  (in’) 

335 

335 

Weight  (pounds) 

10 

12 

Power  (watts) 

27 

45 

Cost* 

$4,100 

$7,300 

*In  quantities  of  5,000 
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Figure  11.  Power  Supply  Subsystem  for  Distributed  Network 
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aiul  Navigation  l illcr  algorithms  arc  assigned  to  one  Pli.  I'rom  Table  7.  the  algorithm  memory 
rei|uirements  are  4300  words  PROM  (instruetion)  and  2800  words  RAM  (data). 

laeh  Fl\  is  controlled  by  a local  table-driven  executive  with  aj^propriate  task-dependent 
table  data,  l or  this  executive.  SOO  words  ol'  instruction  memory  are  required  plus  80  words  ol 
data  memory  lot  each  separate  algorithm  to  be  executed.  Therefore,  the  total  PP  memory 
retpnred  is  4800  wonls  ol  PROM  and  2db0  wonls  of  RAM.  In  order  to  meet  these  requirements, 
one  PMM  anil  one  DMM  are  required  in  addition  to  the  memory  available  on  the  MPM. 
riierefore,  the  following  module  complement  is  required  lor  this  PI;: 

MPM 
SIMM 
lOIM 
VRM 
PMM  ( I ) 

DMM  ( I ) 

Utilization  of  available  PROM  is  85  percent  (4800/5632)  and  utilization  of  RAM  is  58  percent 
(2960/5120). 

Also,  from  Table  7,  the  throughput  requirement  for  these  two  algorithms  is  100  KOPS.  The 
local  executive  throughput  requirement  is  taken  as  10  percent  of  the  total  algorithm  load. 
Therefore,  utilization  of  available  throughput  is  59  percent  (1 10/185).  From  Table  12  the  weiglit 
of  this  PH  is  I I pounds  with  a power  requirement  of  36  watts. 

3.  Ground  Support  Equipment 

Ihere  are  no  major  differences  in  the  ground  support  equipment  requirements  for  the  three 
processing  systems  considered  in  this  study.  Ground  support  equipment  will  be  required  at  three 
levels: 

Organizational  Level 
Intermediate  Level 
Depot  Level. 


At  the  organizational  or  flight  line  level,  each  processing  system  is  designed  so  that  self-test 
and  built-in  test  (BIT)  will  detect  99  percent  of  the  probable  failures  and  isolate  94  percent  of 
the  detected  failures  to  the  proper  line  removable  unit  (LRU).  Maintenance  action  at  the 
organizational  level  will  be  limited  to  replacing  LRUs.  Equipment  for  programming  characteristics 
of  the  specific  mission  also  will  be  required  at  the  organizational  level. 

At  the  intermediate  level,  the  design  goal  is  fault  isolation  to  the  defective  .shop  replaceable 
unit  (SRU)  for  90  percent  of  all  malfunctions  using  automatic  test  equipment  and  BIT  in  the 
LRUs.  Isolation  to  the  defective  SRU  and  one  other  should  be  accomplished  for  100  percent  of 
all  malfunctions. 

At  the  depot  level,  SRUs  determined  repairable  will  be  tested  and  defective  components 
isolated  by  using  automatic  test  equipment.  The  design  goal  is  isolation  to  4 components  for 
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80  percent  of  the  possible  faults,  8 components  for  95  percent  of  possible  faults  and 
10  components  for  100  percent  of  possible  faults. 

B.  CENTRALIZED  SYSTEM 

The  computer  for  the  Centralized  system  must  meet  two  basic  requirements-total  memory 
size  and  peak  throughput.  From  Table  8 through  Table  10,  a peak  throughput  requirement  of 
381.5  KOPS  occurs  during  segment  8 of  the  strike  mission.  From  Table  11,  the  maximum 
algorithm  memory  requirement  is  49,075  words  for  the  strike  mission. 

For  purposes  of  this  program,  the  Texas  Instruments  MARC  IVl 6-bit  computer  is  selected 
for  use  in  the  Centralized  processing  system.  The  MARC  IV  is  considered  to  be  representative  of 
several  currently  available  military  computers  which  can  satisfy  the  above  processing  requirement. 
The  MARC  IV  includes  a serial  bus  interface,  64K  words  of  core  memory,  and  a power  supply. 
Additional  detail  on  the  MARC  IV  is  shown  in  Table  15.  For  an  instruction  mix  of  80  percent 
short  (1  ns)  and  20  percent  long  (5  ms),  the  throughput  capacity  of  the  MARC  IV  is  555  KOPS. 

Block  diagrams  of  the  Centralized  system  are  shown  in  Figure  12  through  Figure  14  for  the 
three  mission  configurations.  The  remote  terminal  interfaces  shown  in  these  block  diagrams 
provide  for  interface  between  the  network  bus  and  the  ARPV  subsystems.  In  terms  of 
complexity,  a remote  terminal  interface  is  equivalent  to  an  SBIM  (two  printed  wiring  board)  plus 
additional  control  logic.  Therefore,  for  purposes  of  this  study,  the  following  characteristics  are 
assumed  for  each  remote  terminal  interface: 

Three  printed  wiring  boards 
Power-23  watts 
Weight-3  pounds 
Volume-94.5  in^. 

Including  provisions  for  a relatively  complex  multitask  executive,  the  processing 
requirements  for  the  Centralized  system  are  51,200  words  of  memory  plus  a peak  throughput  of 
411  KOPS.  '.llierefore,  utilization  of  available  memory  is  78  percent  and  utilization  of  available 
throughput  i-  74  percent.  The  capacity  of  the  Centralized  system  can  be  expanded  by  adding 
another  MARC  IV  to  the  system  or  by  adding  remote  terminals  which  contain  processing 
resources. 


The  peak  bus  traffic  for  the  strike  configuration  of  the  Centralized  system  was  determined 
using  the  SNS.  Major  components  of  the  peak  bus  traffic  during  segment  8 of  the  strike  mission 
are: 


Total  Traffic 
Traffic  Utilized  for  Data 
Traffic  Utilized  for  Header 
Traffic  Utilized  for  Gap 


39.65  kbps  (kilobits  per  second) 
24.80  kbps  (62.55  percent) 

13.20  kbps  (33.29  percent) 

1.65  kbps  (4.16  percent) 
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Figure  12.  Centralbed  System -Strike  Configuration 
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l/P-SCRIAL  BUS  INTERFACE 


Figure  14.  Centralized  System~EW  Conflguration 


TABLE  15.  MARC  IV  CHARACTERISTICS 


Type 

Number  system 

Data  word  length 

Instruction  word  lengtli 

Memory  (Core) 

Access  line 

Register  complement 


Instruction  repertoire 

Instruction  execution  times 
Add 

Multiply 

Input/Output 


Interrupts 

Physical  characteristics 
Weight 
Volume 
Power 

Cost 


Parallel 

Binary,  2's  complement 

16  bits  and  32  bits 

16  bits  and  32  bits 

Expandable  to  64K  words 
460  nanoseconds 

8 16-bit  general  registers 
2 16-bit  base  registers 
4 floating  point  registers 

User-accessible  status  words  consisting  of  tour  Ib-Dtt 
words: 

Program  counter 

Overflow  and  condition  code  register 
Interrupt  mask 

81  basic  instructions 


1 MS 

5 ms 

1 16-bit  parallel  bilateral  channel 
3 serial  channels  consisting  of  two  data  buses  each 
1 serial  channel  for  maintenance  interface 

24  prioritized  interrupts 


1 10  pounds 
4110  in’ 

500  watts 

S80.000  in  quantities  of  500 
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C.  DP/M  SYSTEM 


llic  primary  guiddino  in  designing  the  DP/M  processing  system  is  partitioning  the  avionic 
computational  rei-iuirements  by  task.  Each  major  task  and/or  subsystem  (sensor/actuator)  of  the 
aircraft  is  assigned  its  own  PE.  Inter-PE  communication  is  achieved  via  the  network  bus. 

BliKk  diagrams  of  the  DP/M  system  are  shown  in  Figure  15  through  Figure  17  for  the  three 
mission  configurations.  I'able  16  provides  a summary  of  DP/M  system  characteristics. 
Characteristics  of  individual  PEs  within  the  DP/M  system  are  shown  in  Table  17.  Task 
assignments  and  module  complement  for  core  and  mission-specific  PEs  are  shown  in  Table  18 
through  Table  21. 

Utilization  of  processing  resources  within  the  DP/M  system  is  shown  below; 


Percent  Utilization 


DP/M  Network 

PROM  Memory 

RAM  Memory 

Throughput 

Core 

72 

43 

14.7 

Strike 

58.5 

35.7 

18.9 

Reece 

49.4 

30.2 

10.8 

EW 

67.5 

19.5 

1.9 

Margin  for  growth  is  more  than  adequate,  considering  that  further  PROM  or  RAM  can  be  added 
to  existing  PEs  very  easily.  For  unusual  requirements  that  may  arise,  the  system  can  be  expanded 
by  adding  new  PEs. 


Peak  bus  traffic  for  segment  8 of  the 
strike  configuration: 

Total  traffic 
Traffic  utilized  for  data 
Traffic  utilized  for  header 
Traffic  utilized  for  gap 


strike  mission  is  summarized  below  for  the  DP/M 
101.25  kbps 

52.20  kbps  (51.56  percent) 

43.60  kbps  (43.06  percent) 

5.45  kbps  (5.38  percent) 
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Figure  16.  DP/M  System -Recce  Configuration 
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TABLE  16.  SUMMARY  OF  UP/M  SYSTEM  CHARACTERISTICS 


Core 

Total  PROM  available 
Total  PROM  used 

47,104 

34,010 

Total  R.AM  avatlable 
Total  R.AM  used 

28,672 

12,335 

Total  ROPS  available 
Total  KOPS  used 

2,220 

325.85 

Total  volume  (in^) 

4,200 

Total  power  (watts) 

367 

Total  weight  (nouiids) 

124.5 

Number  of  PEs 

12 

Cost  ($K) 

52.6 

System  Function 


Strike 

Recce 

EW 

15,872 

10,240 

4,608 

9,290 

5,060 

3,110 

9,216 

8,192 

3,072 

3,290 

2,470 

600 

925 

740 

555 

175.45 

79.75 

10. 

1,675 

1,340 

1,005 

148 

117 

81 

51.5 

41 

30 

5 4 3 

21.9  17.5 


13.2 


TABLE  17.  DP/M  SYSTEM  PE  CHARACTERISTICS 
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TABLE  18.  TASK  ASSIGNMENT  FOR  DP/M  CORE  AVIONICS 

Modules  Per  PE 


Processing  Element 

Tasks  Assigned 

SBIM 

lOIM 

MPM 

PMM 

DMM 

VRM 

Communications 

Narrowband  Data  Link 
Subsystem  Service 

1 

1 

1 

0 

0 

1 

Instrmncnlation 

Aircralt  Instiumentation 

1 

1 

1 

0 

0 

I 

Altimeter 

Radar  Altuneter  Subsystem 
Service 

1 

1 

1 

0 

0 

1 

Bus  Control 

Bus  Control,  Bulk  Storage 
Subsystem  Service 

1 

I 

1 

0 

1 

1 

GPS 

GPS 

1 

1 

1 

3 

1 

1 

MLS 

Microwave  Landing  System 

1 

1 

1 

0 

0 

1 

INS 

INS,  Navigation  Filter 

1 

1 

1 

1 

1 

1 

Fliglit  Control 

Flight  Control 

1 

1 

1 

1 

0 

1 

Guidance 

Guidance,  Steering 

1 

1 

1 

1 

0 

1 

IFF 

IFF  Subsystem  Service 

1 

1 

1 

0 

0 

1 

Mission  Control 

Mission  Control,  Status  Monitor 

1 

0 

1 

1 

1 

1 

Air  Data 

Air  Data 

1 

1 

1 

0 

0 

1 

TABLE  19.  TASK  ASSIGNMENT  FOR  DP/M  STRIKE  AVIONICS 

Processing  Element 

Tasks  Assigned  SBIM 

lOIM 

Modules  Per  PE 
MPM  PMM 

DMM  VRM 

Weapon  Station 

Weapon  Station  Subsystem  1 

Service 

1 

1 0 

0 1 

Weapon  Delivery 

Line-of  Sigltt  Computation,  I 

Radiation  Sensor  Subsystem 
Service.  Target  Position 
Computation,  impact  Point 
Computation 

I 

1 I 

0 1 

TERCOM 

TERCOM  1 

1 

I 1 

1 1 

FLIR 

FLIR  Subsystem  Service  1 

1 

1 0 

0 1 

Wideband  Data  Link 

Wideband  Data  Link  Subsystem  1 

1 

1 0 

0 1 

Service 
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TABLE  20.  TASK  ASSIGNMENT  FOR  DP/M  RECCE  AVIONICS 


Processing  Element 

Tasks  Assigned  SBIM 

Modules  Per  PE 
lOIM  MPM  PMM 

DMM  VRM 

IR  Scanner 

IR  Line  Scanner  Subsystem  1 

Service 

1 1 0 

0 1 

WBDL 

Wideband  Data  Link  Subsystem  1 

1 1 0 

0 1 

TERCOM 

TERCOM  1 

1 1 1 

1 1 

Camera 

Photo  Camera  Subsystem  1 

Service 

1 1 0 

0 1 

TABLE  21.  TASK  ASSIGNMENT  FOR  DP/M  EW  AVIONICS 


Processing  Element 

Tasks  Assigned 

Modules  Per  PE 

SBIM  lOIM  MPM  PMM 

DMM  VRM 

Jammer 

Active  Jammer  Control 

1110 

0 1 

Threat  Warning 

Threat  Warning  Receiver 
Subsystem  Service 

1110 

0 1 

Chaff  Dispenser 

Chaff  Dispenser  Subsystem 
Service 

1110 

0 1 

D.  HYBRID  SYSTEM 

In  the  Hybrid  system,  the  total  ARPV  processing  problem  is  partitioned  by  major 
liinetioital  area.  ARPV  subsystems  and  processing  tasks  which  are  functionally  related  are 
groupeil  together  and  assigned  to  individual  PHs. 

Block  diagrams  of  the  Hybrid  system  are  shown  in  Figure  18  through  Figure  20  for  the 
three  mission  configurations.  A summary  of  the  Hybrid  system  characteristics  is  shown  in 
table  22.  Chaiacteristics  of  individual  PF’s  within  the  Hybrid  system  are  shown  in  Table  23.  Task 
assignments  and  module  complement  for  core  and  mission-specific  PHs  are  shown  in  Tables  24 
thiough  2" 

I'tili/ation  of  processing  resources  within  the  Hybrid  system  is  shown  below: 


Percent  Utilisation 


Hybrid  Network 

PROM  Memory 

RAM  Memory 

Throughput 

Core 

81.8 

54.7 

29.3 

Strike 

58.5 

35.7 

18.9 

Recce 

52.4 

34.5 

14.4 

HW 

36.4 

29.3 

2.9 

Ibis  table  indicates  that  the  Hybrid  system  resources  are  utilized  sliglitly  more  efficiently  than  in 
the  HP'.Vl  case  described  previously.  As  in  the  DP/M  system,  there  is  ample  margin  for  growth  in 
the  Hybrid  system.  Also  PROM  or  RAM  can  be  added  to  existing  PEs  and  the  system  can  be 
expanded  by  adding  new  PEs. 


Peak  bus  traffic  for  segment  8 of  the  strike  mission  is  summarized  below  for  the  Hybrid 
strike  configuration: 


'I'otal  traffic 
Traffic  utilized  for  data 
Traffic  utilized  for  header 
Traffic  utilized  for  gap 


93.90  kbps 

49.80  kbps  (53.03  percent) 
39.20  kbps  (41.75  percent) 

4.90  kbps  (5.22  percent) 
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TABLE  22.  SUMMARY  OF  HYBRID  SYSTEM  CHARACTERISTICS 


System  Function 


Core 

Strilce 

Recce 

EW 

Total  PROM  available 
Total  PROM  used 

.17,888 

31,010 

15,872 

9,2‘)0 

8,704 

4,560 

7,168 

2,610 

Total  RAM  available 
Total  RAM  used 

22,528 

12,325 

9,216 

3,290 

7,168 

2,470 

2,048 

600 

Total  KOPS  available 
Total  KOPS  used 

1,110 

324.8 

925 

175.45 

555 

79.75 

370 

10.6 

Total  volume  (m^  ) 

2,0  lO 

1,675 

1,005 

670 

Total  power  (watts) 

211 

148 

90 

58 

Total  weight  (pounds) 

65.5 

51.5 

31 

20.5 

Number  of  PEs 

6 

5 

3 

2 

Cost  ($K) 

34.8 

29.0 

17,4 

11.6 

52 


TABLE  23.  HYBRID  SYSTEM  PE  CHARACTERISTICS 


^ o o — o 


0 0 — 00 


^ — r-i  O 

m Tf  r<^  Tt 


r-.  — vor-r- 
m r4  n 


oq 

O Tf  o O nO 

— r»  IT) 


ro  m iTi 

fO  « r--  ro  O 


u-i  *rj  I/*) 

00  00  OC  00  00  00 


O O O O o 

sO  C40  00  O r-i  X 

OjN  — sO  — nO 


O O O O o 

X CM  X X m 

— r-  o^  — — 
rl 


O o TT  O O rf 

C'l  fN  <N  ri  ri 

— — O^—  — c>. 
•X  in  — «X  — 


Tf  ^ O ^ 
<N  m (N  rj 
O O — 0^0. 


O Q O O O O 

o o ^ — o 

00^  O^  r 4 o^  r«;  r\ 
rf  ri  — X — 


o o o o o 
m rj  m o 

O m — sO 


rsi  r I sO  X vO 
rn  <N  m r4  fn 
NO  X r*^ 


vO  <N  <N  >o  vO 
cr>  'O  nO  »n  in 


o II 


= 0.1  E 


w c — uu 

oi 


. ♦ 


TABLE  24.  TASK  ASSIGNMENT  FOR  HYBRID  CORE  AVIONICS 


Prucejising  Elemeiil 

Tasks  Assigned  SBIM  lOIM 

Modules  Per  PE 
MPM  PMM 

DMM  VRM 

INS 

Strapdown  Inertial  Navigation,  1 1 

Navigation  Filter 

1 1 

1 1 

GPS 

Global  Positioning  Navigation  1 1 

Update 

1 3 

I I 

Fliglit  Control 

Stabilisation  and  Command  1 1 

Control,  Engine  Control 

I 1 

0 1 

Bus  Control 

Serial  Data  Bus  Control  1 1 

(MIL-STD-1553A)  Bulk  Storage 
Subsystem  Service 

1 0 

1 1 

Mission  Control 

Mission  Control,  Status  1 1 

Monitor,  Air  Data,  Aircraft 
Instrumentation,  Radar 
Altimeter,  Microwave  Landing 
System,  Guidance,  Steering 

1 2 

1 1 

Cominunications 

Narrowband  Data  Link  1 1 

Subsystem  Service,  IFF 
Subsystem  Service 

1 0 

0 1 

TABLE  25.  TASK  ASSIGNMENT  FOR  HYBRID  STRIKE  AVIONICS 

Modules  Per  PE 

Processing  Element 

Tasks  Assigned  SBIM  lOIM 

MPM 

PMM 

DMM  VRM 

Weapon  Station 

Weapon  Station  Subsystem  1 1 

Service 

1 

0 

0 1 

Weapon  Delivery 

Line-of-Sight  Computation,  1 1 

Radiation  Sensor  Subsystem 

Service,  Target  Position 

Computation,  Impact  Point 

Computation 

1 

1 

0 1 

TERCOM 

TERCOM  1 1 

1 

1 

I I 

FLIR 

FLIR  Subsystem  Service  1 1 

1 

0 

0 1 

Wideband  Data  Link 

Wideband  Data  Link  Subsystem  1 1 

Service 

I 

0 

0 1 

TABLE  26.  TASK  ASSIGNMENT  FOR  HYBRID  RECCE  AVIONICS 


Modules  Per  PE 

Processing  Element 

Tasks  Assigned 

SBIM 

lOIM 

MPM  PMM 

DMM  VRM 

Imagery 

Photo  Camera  Subsystem 
Service,  Infrared  Line  Scanner 
Subsystem  Service 

1 

1 

1 0 

0 1 

Wideband  Data  Link 

Wideband  Data  Link  Subsystem 
Service 

1 

1 

1 0 

0 1 

TERCOM 

TERCOM  111! 

TABLE  27.  TASK  ASSIGNMENT  FOR  HYBRID  EW  AVIONICS 

Modules  Per  PE 

1 1 

Processing  Element 

Tasks  Assigned 

SBIM 

lOIM 

MPM  PMM 

DMM  VRM 

ECM 

Threat  Warning  Subsystem 
Service,  Active  Jammer  Control 

1 

1 

1 I 

0 1 

Chaff  Dispenser 

Chaff  Dispenser  Subsystem 
Service 

1 

1 

1 0 

0 1 

I 


9-01  X 90V8SI 


Figure  21 . Reliability  Prediction  for  DP/M  System-Strike  Configuration 


E.  RELIABILITY  ANALYSIS 


. I 


A detailed  reliability  study  was  performed  to  aid  in  determining  the  optimum  digital  avionic 
system  for  the  multimission  ARPV  application.  Results  of  the  study  indicate  that  the  Hybrid 
system  is  the  most  attractive  both  from  a hardware  reliability  standpoint  (in  particular  for  safety 
of  flight)  and  also  from  the  increased  reliability  due  to  the  low-complexity  software  used  in  this 
type  of  architecture.  Because  the  structuredness  and  low-complexity  software  attributes  of  the 
Hybrid  system  make  it  easy  to  understand,  maintain  and  alter,  the  overall  reliability  of  this 
system  should  be  primarily  a function  of  the  hardware.  The  primary  result  of  the  reliability 
study  is  the  prediction  of  a minimum  hardware  reliability  of  607  hours  MTBF  for  any  mission 
configuration  of  the  Hybrid  system.  The  corresponding  operational  reliability  based  on  a 1-hour 
mission  is  0.998.  The  following  paragraphs  describe  the  methods  and  assumptions  used  in  making 
the  hardware  reliability  predictions  and  the  results  of  these  predictions.  In  addition,  a description 
of  some  of  tlie  software  reliability  considerations  is  given. 

1.  Hardware  Reliability 

Results  of  the  hardware  reliability  predictions  are  shown  in  Table  28  for  the  three  difterent 
processing  systems  (DP/M,  Hybrid  and  Centralized)  considered.  As  shown  in  Table  28,  both  total 
serial  and  mission-success  predictions  were  performed  for  all  three  mission  configurations  (Strike, 
Recce  and  EW)  of  each  system.  Aircraft  safety  of  flight  predictions  also  were  performed  for  eacli 
of  the  core  systems.  The  total  serial  or  total  system  predictions  are  indicative  of  the  reliability  of 
the  various  system  configurations  assuming  any  failure  is  critical,  e.g.,  from  a maintenance 
standpoint.  For  the  mission-critical  or  mission-success  predictions,  only  those  parts  and 
assemblies  were  considered  which  could  cause  a given  mission  to  be  unsuccessful  if  they  failed. 
Likewise,  for  the  flight-critical  or  aircraft  safety-of-flight  predictions  only  those  assemblies 
affecting  flight  safety  were  considered.  A detailed  prediction  chart  for  each  case  shown  in 
Table  28  is  included  in  Appendix  E.  For  illustrative  purposes.  Figures  21  through  23  are  included 
here  to  show  block  diagrams  of  the  most  complex  mission  configurations  (strike  mission)  for  the 
three  different  systems  considered. 


TABLE  28.  MTBF  SUMMARY  FOR  ARPV  AVIONICS  PROCESSING  SYSTEMS 

MTBF  (hours) 


Reliability  Model 

DP/M 

4S'“C  80°C 

Hybrid 

45°C  80°C 

Centralized 
4S°C  80°C 

Strike  Mission  (Total  Serial) 

729 

464 

962 

607 

1,001 

718 

Strike  Mission  (Success) 

928 

588 

1,084 

682 

1,104 

797 

Recce  Mission  (Total  Serial) 

775 

493 

1,110 

699 

1,104 

797 

Recce  Mission  (Success) 

1,019 

646 

1,110 

699 

1,164 

843 

EW  Mission  (Total  Serial) 

842 

538 

1,221 

770 

1,104 

797 

EW  Mission  (Success) 

1,129 

717 

1,353 

854 

1,230 

894 

Aircraft  Safety  of  Flight 

1,586 

1.018 

1,874 

1,192 

1,485 

1,096 

1 

I 


N 
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Figure  22.  Reliability  Prediction  for  Hybrid  System-Strike  Conngiiration 
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Figure  23.  Reliability  Prediction  for  Centralized  System-Strike  Configuration 


Fuiliirc  Kites  used  in  making  the  reliability  predictions  were  obtained  from  MIL-HDBK-21  7B 
and  Texas  Instruments  data  using  airborne  uninhabited  environmental  K factors  and  part  ambient 
temperatures  of  45°  and  80°C.  Maximum  use  of  JANTX  and  established  reliability  parts  and 
mature  microelectronic  devices  (purchased  to  MlL-M-38510  specifications)  was  also  assumed.  All 
predictions  were  fust  performed  at  80°C  (70°C  ambient  + I0°C  assumed  heat  rise)  to  determine 
the  reliability  of  the  various  systems  under  worst  case  conditions.  Then  the  predictions  were 
performed  at  45°C  (35°  ambient  + 10°C  assumed  heat  rise)  to  illustrate  the  effect  of  operating 
the  system  at  a reduced  temperature  by  means  of  cooling  air. 

The  reliability  predictions  of  Table  28  indicate  that  the  MTBFs  at  80°C  are  higher  in  most 
cases  for  the  Centralized  system.  The  MTBFs  of  the  Flybrid  system  are  approximately  100  hours 
less  in  all  cases  except  aircraft  safety  of  (light.  In  this  latter  case,  the  MTBF  of  the  Hybrid 
system  is  considerably  higher  due  to  natural  partitioning  of  system  operations  along  functional 
lines.  That  is,  much  of  the  circuitry  affecting  aircraft  safety  of  flight  is  independent  for  the 
Hybrid  system.  In  every  case  except  aircraft  safety  of  (light,  the  MTBF  of  the  DP/M  system  is 
lower  than  that  of  the  Hybrid  and  Centralized  systems,  primarily  due  to  the  increased  parts 
count  resulting  from  complete  partitioning  along  task  lines. 

As  shown  by  the  data  in  Table  28,  reducing  the  temperature  from  80°  to  45°C  significantly 
improves  the  MTBF  of  all  configurations  considered.  It  is  especially  interesting  to  note  that  this 
reduction  in  temperature  allows  the  MTBF  of  the  Hybrid  system  to  almost  equal  that  of  the 
Centralized  system  in  some  cases  and  to  exceed  it  in  others.  At  this  point,  it  is  important  to 
remember  that  the  DP/M  and  Hybrid  systems  utilize  high  complexity  microelectronic  devices 
(i.e.,  ROMS,  microprocessors,  etc.)  which  allow  considerable  reduction  in  total  parts  count.  The 
Centralized  system  primarily  utilizes  relatively  low  complexity  devices.  At  the  present  time  (refer 
to  MIL-HDBK-2 1 7B)  the  failure  rates  of  the  high  complexity  integrated  circuits  are  much  larger 
at  a given  temperature  than  low  complexity  devices.  In  addition  the  failure  rates  of  the  high 
complexity  devices  vary  more  rapidly  for  a given  change  in  temperature.  The  following  example 
using  MIL-HDBK-2 17B  is  given  to  illustrate  this  situation.  The  failure  rate  equation  for  the 
example  is: 

Xp  = TTl  TTq  (Cl  TT-J-J  + Cj  TTg) 

where 

Xp  = device  failure  rate  in  F/10* 

ttl  = device  learning  factor  determined  from  table  2. 1.5-1 
of  MIL-HDBK-21 7B 

iTq  = quality  factor  determined  from  table  2. 1.5-1  of 
MIL-HDBK-2 17B 

iTj  = temperature  acceleration  factor  determined  from 
MIL-HDBK-21 7B 

7T^  = application  environment  multiplier  determined  from 
table  2. 1.5-3  of  MIL-HDBK-21 7B 

C, , Cj  = circuit  complexity  factors  determined  from  table 
2. 1.5-5  of  MIL-HDBK-21 7B  for  low  complexity 
digital  devices  and  from  table  2. 1.5-8  of  MIL-HDBK- 
21 7B  for  memory  devices. 


Calculations 


Device  TVpe 
4096-bit  ROM 

4096-bit  ROM 


Typical  TTL  Device 
(lO-gate  complexity) 

Typical  TTL  Device 
(10-gate  complexity) 


Assumptions 

Part  Ambient  Temperature  = 80°C 
Tj  = 110°C 

Part  Ambient  Temperature  = 45°C 
Tj  = 75°C 

Part  Ambient  Temperature  = 80°C 
Tj  = 90°C 

Part  Ambient  Temperature  = 45°C 
Tj  = 55°C 


Xp  = (1.0X2)((0.17X3.6)+(0.07X6)1 
= 2.064 

Xp  =(1.0X2)[(0.17XI.O)+(0.07X6)1 
= 1.18 

Xp  = ( 1.0)(2)  [(0.0061X1  .8)+(0.0089X6)] 
= 0.129 

Xp  = (1.0X2)[0.0061X0.44)-^(0.0089X6)1 
= 0.112 


For  the  4096-bit  ROM,  the  ratio  of  the  failure  rate  of  80°C  to  that  at  45°C  is  1.75  ( = 
2.064/1.18)  while  the  corresponding  ratio  for  the  typical  TTL  device  of  10-gate  complexity  is 
1.15  (=  0.129/0.112).  This  illustrates  that  the  relative  change  in  failure  rate  resulting  from 
temperature  changes  is  much  greater  for  the  higher  complexity  devices  than  for  the  lower 
complexity  devices.  Observation  of  the  above  calculations  indicates  that  the  failure  rate  of  the 
higher  complexity  devices  is  not  only  greatly  influenced  by  the  increased  complexity  but  also 
greatly  affected  by  the  higher  junction  temperatures  resulting  from  higher  levels  of  power 
dissipation.  It  should  be  noted  that  the  relatively  high  failure  rate  of  the  high-complexity  devices 
is  often  offset  by  the  composite  failure  rate  of  the  large  number  of  low<omplexity  devices 
which  they  replace.  That  is,  use  of  low-complexity  devices  to  perform  the  same  function  as  that 
of  a microprocessor  or  other  high-complexity  device  would  not  only  greatly  increase  the  overall 
parts  count,  cost,  and  packaging  space  but  would  also  increase  the  overall  failure  rate  since  the 
failure  rate  of  the  higher  complexity  devices  is  generally  less  than  the  combined  failure  rate  of 
the  lower  complexity  devices  required  to  perform  the  same  function. 


Considering  the  tradeoff  factors  of  reliability,  cost,  ease  of  testing  and  overall  flexibility,  the 
Hybrid  system  appears  to  be  the  most  attractive.  From  a pure  reliability  standpoint,  the  MTBF 
of  the  Hybrid  system  is  very  close  to  that  of  the  Centralized  system  for  some  cases  and  actually 
higher  for  other  cases.  The  aircraft  safety-of-fliglit  MTBF  for  the  Hybrid  system  greatly  exceeds 
that  of  the  Centralized  system  because  the  circuitry  associated  with  aircraft  safety  of  flight  for 
the  Hybrid  system  is  independent  of  most  of  the  other  circuitry.  This  circuitry  independence 
does  not  exist  for  the  Centralized  system.  Because  of  the  relatively  high  MTBFs  that  are 
achievable  for  the  Hybrid  system,  redundancy  was  not  considered  necessary  at  this  time.  The 
lowest  predicted  MTBF  for  the  Hybrid  system  was  607  hours  for  the  strike  mission  under  worst 
case  conditions.  Although  no  redundancy  was  considered  at  this  time,  implementation  of 
redundancy  for  the  Hybrid  system  is  much  easier  and  more  cost  effective  than  for  the 
Centralized  case.  In  the  case  of  the  DP/M  system,  the  added  flexibility  resulting  from  complete 
partitioning  along  task  lines  does  not  appear  to  be  sufficient  to  offset  its  higlier  cost  and  lower 
reliability  resulting  from  the  use  of  a much  larger  number  of  modules. 
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TABLE  29.  SOFTWARE  RELIABILITY  SOURCES 


Title 


Author 


Source 


SoftWdie  Reliability:  Martin  L.  Sliooman 

Measuiement  Models 


Proceedings  1975  Annual  Reliability  and 
Maintainability  Symposium 


Embedded  Computer  System 
Software  Reliability 


Lt.  Col.  John  U.  Manley.  USAF  Defense  Managemenl  Journal,  Vol.  II.  No.  4. 

October,  1975 


Testing  Strategies  for 
Software  Reliability 
Assessment 


John  R.  Brown 
Advanced  Defense  Systems 
TRW  Systems 
Redondo  Beach,  California 


Prepared  for  the  Joint  Logistics  Commander’s 
Electronics  Systems  Reliability  Workshop 
May,  1975 


Special  Report  for  die 
SRWG  on  the  International 
Conference  on  Reliable 
Software 


Peter  Wegner 
Brown  University 
Providence,  Rhode  Island 


Prepared  for  the  Joint  Logistics  Commander’s 
Electronics  Systems  Reliability  Workshop 
June,  1975 


Software  Reliability  How  James  A.  Ronback 
It  Affects  System  Reliability  CAE  Electronics  Ltd. 

Montreal 


Microelectronics  and  Reliahility,  Vol.  14. 
pages  1 21-140. 


2.  Software  Reliability 

As  part  of  the  reliability  study,  many  articles  on  software  reliability  were  reviewed.  A list  of 
these  articles  and  their  authors  is  included  in  Table  29.  Software  reliability  is  defined  as  the 
probability  that  the  software  will  satisfy  the  stated  operational  requirements  for  a specified  time 
•nterval  or  a unit  application  in  the  operational  environment,  it  has  been  stated  that  the 
complexity  of  investigating  software  reliability  problems  undoubtedly  has  discouraged  academic 
research,  as  witnessed  by  the  lack  of  literature  on  the  subject,  since  clear-cut  conclusions  are 
nearly  impossible  to  derive  from  field  experimentation  on  deployable  systems.  Some  of  the 
primary  causes  of  computer  software  failures  are  (I)  design  and  coding  errors  and  (2)  externally 
caused  failures  such  as  computer  hardware  failures,  interactions  with  other  system  components, 
incorrect  human  inputs  and  environmental  changes.  In  addition,  some  of  the  software 
characteristics  which  make  reliability  determinations  difficult  are: 

Software  interfaces  are  conceptual  rather  than  physical  (there  is  no  easy-to-visualize 
three-prong  plug  and  its  mate) 

There  are  many  more  distinct  paths  to  check  in  software  than  in  hardware 

There  are  many  more  distinct  entities  to  check  (any  item  in  a large  file  may  be  a 
source  of  error) 

Software  errors  generally  come  with  no  advance  warning,  provide  no  period  of  graceful 
degradation,  and,  more  often,  provide  no  announcement  of  their  occurrence. 

Many  system  failures  are  created  due  to  complexity  alone.  As  in  the  case  of  hardware,  the 
structure  of  software  may  evolve  into  a system  which  is  difficult  to  understand,  hard  to  maintain 
and  hazardous  to  alter  because  many  parts  of  the  system  are  so  tightly  coupled  to  each  other.  As 
indicated  previously  in  this  report,  studies  prior  to  this  ARPV  study  have  shown  that  the  digital 
data  processing  associated  with  the  avionics  tasks  can  be  easily  partitioned  into  a number  of 
simpler  tasks.  Tliis  fact  tends  to  simplify  software  for  the  case  of  a distributed  network.  Also, 
the  executive  software  can  be  table  driven,  which  makes  it  flexible  and  provides  for  separation  of 
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sy>ti.‘in  U>tiic  ;iiul  iipplk.itioii  soltvs;iro  iiUHluk's.  'Hie  stnieliiredness  aiul  lowei  eomplexily 
■ittrilniles  ol  llie  l)l’/M  aiul  Kylirid  systems  make  lliein  easier  to  imderstaiid.  maiiilam  and  alter 
riius,  they  eaii  he  implemented  laster.  he  eheeked  out  more  tlioroiielily,  and  prosiile  Inplier 
relial'ility.  The  maior  eontrihntion  that  is  made  lowarrl  system  reliability  is  the  testahilily  ol  a 
well  strnetnred  software  ilesiftn  wlneh  ean  he  aeliieved  in  a distrihnted  (iroeessiiif;  system 

The  tests  rerpiired  for  eaeh  software  module  are  easiei  to  desiyii  and  thus  ean  he  made  more 
thorontth.  The  thoronglmess  of  the  testing  pei formed  ean  be  monitored  and  aeeepted  with  more 
eonfidenee.  With  nnstrnetnred  software  systems,  determining  the  eompleteness  of  the  testing  that 
is  done  is  diffienit  and  this  is  what  has  eonditioned  people  to  expeet  a large  number  ol  hugs  in 
software.  Use  of  heirarehically  modular  system  software  is  a neeessity  for  the  discovery  of  riesign 
errors  early  in  the  design  eyele  and  for  prevention  of  many  error  types  altogether.  .Also 
heirarchical  modularity  promotes  highly  localized  error/change  effects  so  that  sottware  modules 
can  he  modified  without  introducing  errors  or  affecting  other  modules. 

Another  factor  influencing  software  reliability  is  the  type  of  programming  language  selected. 
Use  of  higher  order  languages  results  in  programming  tlexibility,  operational  reliability, 
maintainability,  and  lower  development  risk  associated  with  software  handover  to  new 
programmers,  reduced  training  prohleins,  software  commonality,  etc.  However,  all  the  factors 
which  affect  the  tradeoff  of  IIOL  versus  Al,  must  be  considered  since  there  is  no  universally  firm 
answer  to  this  trade  as  yet. 

file  software  reliability  features  along  with  the  hardware  reliability  achievable  make  the 
Hybrid  system  highly  attractive  from  a reliability  standpoint. 

F.  MAINTAINABILITY  ANALYSIS 

In  preparing  data  for  input  to  the  L.CC  analysis,  several  assumptions  and  considerations  liarl 
to  be  made  in  the  absence  of  linn  data.  I hose  considerations  pertaining  to  the  operation  and 
maintenance  of  the  system  are  rliscussed  in  this  subsection. 

1.  Assumptions 

file  entire  complement  of  aircraft  w'as  considered  to  be  et|ually  rlistributed  between  three 
locations.  The  eipiipinent  w'as  to  remain  essentially  in  storage  throughout  the  entire  10-year 
anticipated  lifetime.  Lach  of  the  locations  was  considered  to  lly  each  eipiipmenl  for  1 hour  each 
year  or  approximately  four  tliglits  per  week  average.  This  effort  was  intended  to  maintain  skills 
as  well  as  keep  a check  on  the  status  of  the  equipment. 

Test  equipment  assumptions  included  programming/testing  equipment  at  each  organizational 
level,  testing  ei|uipment  for  intermediate  maintenance  at  each  location  plus  one  at  some  central 
location  for  preparing,  evaluation,  and  rermement  of  testing  proceilures  and  programs,  and  one 
central  depot  test  set.  This  rei|uired  three  sets  of  organizational  level  equipment,  font  sets  of 
intermediate  level  equipment,  and  one  set  of  ilepol  eiiuipment. 

The  operational  maintenance  concept  used  in  the  study  assumed  the  aircraft  wouUI  be 
removed  from  storage  and  moved  to  a night  preparation  area.  The  aircraft  would  be  fueleil. 
stores  loaded,  a built-in  test  (Uff)  performed  on  the  electronics,  the  mission-specific 
requirements  programmed  in.  and  the  aircraft  removed  to  the  launch  area.  .Alter  recovery  , the 
aircraft  wonhl  be  down-loailed.  a Bff  performed,  and  the  aircraft  prepared  for  storage  or 


a-aMitlgured  lor  the  next  mission.  At  any  time  a maH'iinction  is  detected  during  built-in  testing 
or  programming,  tlie  detective  unit  will  be  isolated  using  the  built-in  test  or  the  test  equipment 
associated  with  the  programming  equipment.  The  defective  unit  would  be  removed  and  replaced 
by  a unit  from  stock.  The  defective  unit  would  be  tested  in  the  intermediate  shop,  the  defective 
module  isolated,  removed,  and  replaced,  and  the  unit  tested  and  returned  to  supply.  The 
defective  module  would  be  returned  to  de/)Ot  for  testing,  fault  isolation,  and  repair  based  on  a 
code  supplied  by  a detailed  repair  level  study  performed  on  each  module.  This  detailed 
level-of-repair  study  would  be  a part  of  the  overall  system  design  program. 

The  total  operating  time  per  sortie  on  the  equipment  including  the  tlying  time,  self-test 
time,  and  programming  time  was  assumed  to  be  approximately  1.5  hours.  (This  comprises  I hour 
flying.  5 minutes  total  self-test  before  aiul  after  lliglit,  and  25  minutes  programming  time.) 

The  Ml  hMA  was  determined  by  a “K”  factor  applied  to  the  MTBK.  The  “K”  factor  is 
determined  by  the  knowledge  that  the  system  will  not  reach  its  mature  failure  rate  by  the  design 
freeze  point  in  a production  program,  field  history  as  well  as  calculations  show  that  the 

appropriate  factor  will  be  approximately  0.2  with  approximately  25  percent  of  these 
maintenance  actions  resulting  in  no  reyrair  action  requiring  intermediate-level  maintenance.  The 
"K"  factors  used,  then,  are  MTBMA  = 0.2  MTBF  and  the  maintenance  actions  requiring 

intermediate  maintenance  activity  = 0.25  MTBF. 

For  purpo.ses  of  this  program,  the  quantity  of  maintenance  actions  allowing  a throwaway 
concept  at  the  intermediate  level  must  be  minimized  due  to  the  scope  of  a study  required  to 
.malyze  each  module  individually  after  design.  Tliis  throwaway  decision  is  dependent  on  the  cost 
ol  the  printed  wiring  boards.  Preliminary  review  of  the  PWB  design  and  cost  data  indicates  that 
approximately  20  to  30  percent  of  the  PWBs  may  be  discarded  rather  than  repaired.  Tliese 
numbers  were  used  in  the  LCC  calculations. 

rite  number  of  people  associated  with  maintenance  was  calculated  based  on  the  assumption 
of  one  man  trained  at  depot  for  module  repair  and  eiglit  per  site,  comprising  one  supervisor, 
three  organizational  and  four  intermediate  people.  Less  than  100  percent  utilization  of  personnel 

on  this  equipment  was  <tctermined,  but  the  loading  was  designed  for  the  ARPV  system  to 

become  fully  operational  on  a 24-hour  basis  in  order  to  fly  combat  missions.  For  daily 
operation,  three  people  would  be  expected  to  perform  other  duties  as  a three-shift  operation  is 
unlikely. 

These  assumptions  were  made  to  simidate  the  most  likely  activity  to  be  experienced  by  the 
equipments.  Lxcept  where  differences  in  the  candidate  systems  caused  a difference  in  the 
assumptions.  Identical  values  were  used  in  each  of  the  three  systems  analyzed. 

2.  Analysis  Results 

Mean-time-to-repair  predictions  were  made  on  each  system  at  all  maintenance  levels.  The 
organizational  level  prediction  assumes  a second  man  during  the  0.1-hour  period  of  physically 
removing  and  replacing  the  central  computer  on  the  Centralized  system.  The  second  man  is  not 
required  for  the  DP/M  or  Hybrid  systems  nor  for  the  intermediate  and  depot  levels. 
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Uvel 

Centnlized 

(man-houn) 

Hybrid 

(man-hours) 

DP/M 

(man-hours) 

Organizational 

0.5 

0.25 

0.25 

Intermediate 

1.0 

0.5 

0.5 

Depot 

0.8 

0.8 

0.8 

The  significant  difference  in  the  organizational  level  prediction  is  the  weight  of  the  units. 
Fault  isolation  will  be  essentially  the  same,  as  will  the  programming  and  testing.  The  numerous 
small  units  of  the  distributed  networks  make  those  systems  much  easier  to  repair. 

The  significant  difference  in  the  intermediate  level  prediction  is  the  ease  of  testing,  fault 
isolation,  and  location  of  the  defective  modules.  Again,  the  smaller  units  have  advantages  over 
the  centralized  computer  due  to  similarity  of  the  units. 

The  depot  level  maintenance  prediction  was  taken  from  recent  demonstrations  of  similar 
complexity.  No  significant  difference  between  the  systems  was  anticipated  at  this  level,  so  the 
repair  times  are  identical. 


SECTION  IV 

COST  OF-OWNERSHIP  ANALYSIS 


A.  DEFINITION  OF  OPERATIONAL/MAINTENANCE  CONSIDERATIONS 

1 . Cieneral 

The  life-cycle  cost  model  for  the  ARPV  processing  system  is  but  one  of  the  elements  in  the 
overall  LCC  analysis  flow  as  shown  in  Figure  24.  Very  essential  driving  elements  precede  or 
accompany  the  cost  model.  These  principal  drivers  are  doctrines,  ARPV  system  characteristics, 
and  standard  USAF  cost  factors. 

As  seen  in  Figure  24,  the  procurement  aspects  of  the  ARPV  will  dictate  the  number  ol 
ARPV  vehicles  which  will  eventually  be  available.  The  operational  life-cycle  scenario  is  postulated 
from  the  number  of  ARPV  vehicles  purchased  and  the  mission  requirements;  i.e.,  the  total 
number  of  operating  hours  for  the  ARPV  is  the  result  of  multiplying  the  number  of  ARPVs  by 
the  number  of  average  Hying  hours  per  ARPV  mission.  When  the  number  of  operating  hours  is 
combined  with  the  overall  ARPV  system  characteristics,  maintenance  and  support  concepts  are 
determined.  These  factors  are  then  introduced  into  the  ARPV  processing  system  LCC  model. 

Standard  USAF  cost  factors,  which  are  available  in  the  areas  of  labor  rates,  support 
personnel  turnover  rates,  packaging,  handling  and  transportation  rates,  etc.,  also  are  used  in  the 
ARPV  LCC  model.  These  standard  rates  are  combined  with  best  available  estimates  of  field 
MTBFs,  average  repair  times  per  maintenance  action,  hardware/software  support  equipment  costs, 
etc.,  as  required  model  inputs. 

The  output  of  this  model  is  the  estimate  of  LCC  for  a given  processing  system.  Iterations 
and  sensitivity  analyses  are  then  performed  to  determine  the  accuracy  or  limitations  of  this 
estimate.  The  selected  LCC  model  yields  an  accumulated  dollar  value  for  the  operational  period. 

2.  Operational  Considerations 

The  life-cycle  scenario  and  operational  concept  data  for  the  ARPV  which  was  hypothesized 
for  this  study  is  summarized  as  follows: 

Nine  squadrons  of  50  aircraft  each  (with  strength  of  450  aircraft  at  end  of  10-year 
period) 

5.000  fiying  hours  in  a 10-year,  peacetime,  training  period  (5.000  one-hour  flights) 

Two  percent  attrition  in  peacetime  training  (100  aircraft) 

Original  acquisition  of  550  aircraft  with  450  left  for  the  30-day  combat  at  the  end  ot 
10  years 

5.000  flying  hours  of  combat  operation  in  the  30-day  confiict  (with  most  of  the 
conflict  in  the  first  10  days) 

Peacetime  deployment  is  three  squadrons  at  three  bases.  (Wartime  deployment  is  nine 
squadrons  in  three  clusters  of  three  squadron  bases) 

ARPVs  will  operate  from  austere,  dispersed  bases  which  are  located  10-  to  30-miles 
from  manned  aircraft  bases  which  will  provide  the  peacetime  logistical  support. 

Details  of  the  ARPV  mission  scenarios  are  covered  in  Appendix  A of  this  report. 
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Figure  24.  ARPV  Processing  System  LCC  Analysis 


The  basic  parameters  for  the  processing  system  LCC  analysis  which  are  derived  from  the 
life-cycle  scenario  are; 

550  ARPV  vehicles  (procured  at  the  rates  of  55/year  for  10  years  or  275/year  for 
2 years) 

1.5  operating  hours  per  year  per  ARPV  (based  on  1 flying  hour  per  year  per  aircraft 
and  on  a 1.5:1  operating  to  flying  hour  rate 

10-year  peacetime  period  followed  by  a 30-day  conflict  in  the  1 ith  year. 

These  and  other  operational  factors  were  used  in  the  LCC  analysis  which  is  discussed  in 
subsection  IV. B. 

3.  Maintenance  Considerations 

Maintenance  considerations  were  driven  by  the  following  factors: 

Desire  to  maintain  operational  readiness  during  the  entire  peacetime  period 
Detailed  reliability  predictions  of  the  various  processor  architectures 
Prevailing  USAF  maintenance  doctrines  and  policies. 

These  factors  combine  to  yield  a three-level  maintenance  philosophy  (organizational  or  flight 
line,  intermediate,  and  depot  levels)  using  the  USAF  doctrine  of  no  preventive  maintenance. 
Additional  details  on  reliability  and  maintainability  analyses  for  the  ARPV  processing  systems 
may  be  found  in  Section  HI  of  this  report. 

B.  ANALYSIS  OF  LIFE-CYCLE  COST 

1.  Background 

In  order  to  select  the  most  appropriate  LCC  model  for  this  study,  a number  of  currently 
available  LCC  models  were  reviewed.  In  the  selection  process,  LCC  models  from  all  the  military 
services  were  considered  including  a number  of  versions  of  the  basic  AFLC  model,  the  GPS 
model,  and  the  ARPV-AFLC  model.  In  addition,  a model  developed  by  Texas  Instruments  was 
considered.  This  model  incorporates  a large  number  of  desirable  features  from  other  currently 
available  models.  Experience  with  the  Texas  Instruments  model  has  proven  it  to  be  especially 
useful  in  the  early  analysis  phases  of  a program. 

After  an  evaluation  of  these  various  models,  the  Texas  Instruments  LCC  model  was  selected 
as  the  most  appropriate  one  for  use  in  this  study.  This  model  contains  appropriate  cost 
categories;  it  is  tailored  for  analysis  in  developmental  applications,  and  it  is  computerized.  It  is 
flexible  and  may  be  easily  expanded  or  modified  for  application  in  the  early  study  phases  of 
programs  where  the  amount  of  definition  is  not  completely  known  or  easily  estimated.  For 
example,  the  number  of  line-item  introductions  is  based  on  a total  line-item  count  without 
regard  to  coding,  as  opposed  to  defining  P-coded  line  items  as  found  in  other  models.  A detailed 
discussion  of  this  model  is  presented  in  Appendix  F. 

2.  Methodology 

With  the  LCC  model  selected,  only  a few  alterations  of  the  individual  equations  were 
required  for  adaptation  to  the  ARPV  problem.  The  data  which  had  to  be  estimated  was 
categorized  and  assigned  to  individuals  who  were  either  specialists  or  who  were  very  familiar  with 


those  areas  to  be  estiinateil.  All  estimates  were  made  in  terms  ol' eoiistant  I97h  dollars.  Also 
mature  teeluiology  was  assumeil  lor  all  three  inoeessor  system  desittiis.  Some  data,  such  as 
standard  cost  factors,  were  available  I'rom  Al'LC  and  other  sources.  Appendi.x  (i  is  a collection  ol 
the  final  input  data  useil  in  the  LCC  .malysis.  Hie  use  of  cost  estimating  relationships  (('I'.Rs) 
was  unfortunately  held  to  a minimum  because  of  a lack  of  open  literature  and  ('I  Rs  in  the  areas 
of  microptocessors,  computers,  etc. 

After  collection  and  review  of  this  estimated  data,  the  data  was  input  to  the  ARRV  LCC 
model.  Separate  LCC  estimates  were  determined  for  the  three  processing  systems  (Centrali/.ed, 
J/ybrid  and  I)R/M)  with  appropriate  averaging  over  tlie  three  ARPV  missions  (strike,  recce,  and 

i;w). 

d.  Results 

I'he  results  of  the  life-cycle  cost  analysis  are  summari/ed  in  Table  30  for  the  two  procure- 
ment "options”,  i.e.,  55  systems/year  for  10  years  and  275  systems/year  for  2 years.  As 
expected,  the  shorter  procurement  time  case  is  more  advantageous  than  the  smaller-c\uantity 
longer-procurement-time  case.  The  lowest  LCC  from  this  classical  LCC  analysis  is  the  value  of 
$71,307,003  for  the  Hybrid  system.  275  systems/year  buy. 

It  is  interesting  to  note  in  this  analysis  that  the  acquisition  cost  for  each  system  is  greater 
than  the  sustaining  cost,  b'or  the  275  systems/year  buy,  the  aciiuisition  to  sustaining  cost  ratio 
for  the  Hybrid  system  is  1.51:1;  the  corresponding  ratios  for  the  other  two  systems  are  2.00:1 
(DP/M)  and  2.24:1  (Centrali/.ed).  These  ratios  are  lower  than  normally  expected  for  avionics 
systems  because  of  the  relatively  low  operating  hours  (1.5  hours  of  operating  time  per  year)  and 
the  high  reliabilities  predicted  for  each  of  the  three  processor  configurations. 

The  LCC  results  in  Table  30  do  not  retlect  the  30-day  contlict  period.  For  simplicity  of 
analysis,  this  period  was  chosen  to  follow  the  10  years  of  peacetime.  The  results  of  this 
additional  conflict  period  do  not  alter  the  conclusions  reached;  i.e.,  that  the  Hybrid  system 
exhibits  the  lowest  life-cycle  cost. 

4.  Other  Considerations 


The  acquisition-to-sustaining-cost  ratio  is  determined  in  part  by  the  need  for  operational 
readiness,  since  sustaining  factors  such  as  logistics,  training,  manuals,  and  maintenance  were  held 
at  a level  compatible  with  entering  the  30-day  contlict  at  any  time  during  the  10-year  period. 
With  the  small  amount  of  operating  hours  per  year  per  aircraft,  the  ARPV  sustaining  effort  more 
clearly  approximates  a missile  or  guided  weapons  sustaining  effort  in  which  activities  are  limited 
to  system  test  and  verification  on  a sampling  basis  and  repair  of  the  faulty  systems.  In  the  latter 
situation,  Texas  Instruments  has  observed  that  LCC  analyses  generally  indicate  an  approximate 
4:1  acquisition  to  sustaining  cost  ratio.  If  the  missile/guided-weapons  sustaining  philosophy  were 
adopted  for  the  ARPV,  the  acquisition  cost  of  $42,919,100  for  the  Hybrid  system  (Table  30) 
would  indicate  a sustaining  cost  of  $10,729,775.  This  would  yield  a total  cost  for  the  10-year 
peacetime  period  of  $53,648,875  or  a reduction  of  24.8  percent  in  the  life-cycle  cost. 


I ABLE  30.  SUMMARY  OF  ARPV  PROCESSIN(;  SYSTEM  LCC  RESULTS 


r 

I 

I Processing  System 


Centralized  (C) 

Hybrid  (H) 

DP/M 

55  Systenis/Year,  10  Years 
Acquisition  Cost 
Sustaining  Cost 
Lite  ('ycle  Cost 

(Constant  1976  Dollais) 

$120,1 72,400 
31,392,770 
$151,565,170 

$69,742,600 

27,513,237 

$97,255,837 

$104,150,400 

29,644,200 

$133,794,600 

275  Systems/ Year.  2 Years 
Acquisition  Cost 
Sustaining  Cost 
Ufe  Cycle  Cost 

$ 72,626,640 
32,463,753 
$105,090,393 

$ 42,919.100 
28,387,903 
$ 71,307,003 

$ 61,041,560 
30,500,587 
$ 91,542,147 

(Constant  1976  Dollars) 


S.  Sensitivities  Analysis 

Tite  dominant  factor  or  driver  in  the  life-cycle  cost  for  all  systems  considered  is  the  per-unit 
acquisition  cost.  For  this  reason,  extensive  sensitivity  analyses  were  not  run  on  sustaining  cost 
factors.  A sensitivity  analysis  was  conducted  for  the  procurement  quantities,  i.e.,  55  systems/year 
purchased  for  10-years  or  275  systems/year  purchased  for  2-years.  Tlie  other  two  principal 
life-cycle  cost  factors,  reliability  and  operating  hours,  also  were  investigated. 

Results  of  the  procurement  cpiantity  sensitivities  were  summarized  in  Table  30.  As  expected, 
the  larger  quantity-shorter  procurement  time  yielded  the  lowest  LCC. 

I For  the  second  sensitivity  analysis,  the  effect  of  system  reliability  was  examined.  A 

variation  of  less  than  0.1  percent  resulted  in  the  total  life-cycle  cost  for  a variation  of  an  order 

, of  magnitude  decrease  in  the  mean-time-between-failure  (MTBF  or  XTBF)  and  the 

I 

mean-time-between  maintenance  action  (MTBMA  or  XTBM).  These  results  are  somewhat  dis- 
. torted  in  that  the  processing  system  unit  price  was  not  altered  in  this  analysis.  In  reality,  a 

system  with  an  order  of  magnitude  lower  MTBF  would  not  be  as  expensive  as  the  more  reliable 
system. 

The  final  sensitivity  analysis  involved  the  operating  hours  of  the  processing  system.  For  a 
variation  of  50  to  450  operating  hours  per  year,  an  increase  in  the  life-cycle  cost  of  less  than 
j 2 percent  resulted. 

t 

I Both  the  MTBF  and  operating-hours  sensitivities  indicated  that  the  reliability  of  the  Hybrid 

system  was  indeed  cost-effective  from  an  LCC  point  of  view. 

I 

i In  order  to  show  the  impact  of  the  cost  categories,  the  LCC  for  each  system  (for  the 

I 275/year  buy)  was  examined  for  the  driver  categories.  A summary  of  the  major  cost  categories  is 

presented  in  Table  31  through  Table  33.  As  stated  before,  the  unit  cost  is  the  principal  cost 
factor  for  both  the  acquisition  cost  and  life-cycle  cost.  The  sustaining  costs  contribute  approxi- 
mately 31  percent  to  the  total  l.CC  value  for  each  system.  Recurring  data  management  is  the 
dominant  sustaining  cost  category. 
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TABLE  31.  ANALYSIS  OF  CENTRALIZED  SYSTEM  LCC  DRIVERS 


Percent  of  Percent  of 

Value  Acquisition  Cost  LCC 


Acquisition  Costs 


De;>ign  ami  development 

$ 2,041,233 

2.81 

1.94 

Initial  technical  data 

2,055,900 

2.83 

1.96 

Other  nonrecurring  cost 

133,430 

0.18 

0.13 

Prune  equipment/initial  spares 

67,983,153 

93.61 

64.69 

(includes  installation  and 
first  destination  cost) 

Support  equipment/initiM  spares 

412,924 

0.57 

0.39 



— 

— 

572,626,640 

100.00 

69.11 

Sustaining  Costs 

Maintenance  labor 

S 998 

0.00 

0.00 

Maintenance  material 

4,668 

0.01 

0.00 

Maintenance  documentation 

126 

0.00 

0.00 

Maintenance  packaging  and  transportation 

41 

0.00 

0.00 

Condemnation 

4,755,438 

14.65 

4.53 

Checkout 

1,297,694 

4.00 

1.24 

Energy  consumption 

0 

0.00 

0.00 

Supply  management 

812,186 

2.50 

0.77 

Facility  space 

7,024 

0.02 

0.01 

Recurring  training 

322,680 

1.00 

0.31 

Recurring  data  management 

22,922,697 

70.61 

21.81 

Support  equipment  maintenance 

265,890 

0.82 

0.25 

Software  maintenance 

2,074,311 

6.39 

1.97 

$32,463,753 

100.00 

30.89 

Life  Cycle  Cost 

$105,090,393 

100.00 

Early  analyses  of  these  three  processor  systems  were  made  using  a 5 percent  condemnation 
rate.  This  value  was  judged  to  yield  distorted  sustaining  and  life-cycle  costs.  The  condemnation 
rate  was  reduced  to  1 percent  for  the  analysis  shown  in  this  report.  The  condemnation  cost 
category  contributes  approximately  4 percent  to  the  life-cycle  cost  value  for  each  of  the  three 
systems  considered. 


The  possible  effect  of  using  bit  slice  or  nonhomogeneous  processing  elements  was  not 
analyzed  in  detail.  However,  qualitatively,  it  can  be  stated  that  the  effect  of  such  changes  would 
be  to  increase  the  initial  and  recurring  training,  initial  and  recurring  data,  and  initial  and 
recurring  logistical  costs  in  proportion  to  the  selected  mix. 
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TABLE  32.  ANALYSIS  OF  HYBRID  SYSTEM  LCC  DRIVERS 


Value 

Percent  of 
Acquisition  Cost 

Percent  of 
LCC 

Acquisition  Costs 

Design  and  development 

$ 2,384,756 

5.56 

3.34 

Initial  and  technical  data 

1,842,750 

4.29 

2.58 

Other  nonrecurring  cost 

128,929 

0.30 

0.18 

Prime  equipment/initial  spares  (includes 

38,364,970 

89.39 

53.80 

installation  and  first  destination  costs) 

Support  cquipment/initial  spares 

197,695 

0.46 

0.28 

$42,919,100 

100.00 

60.18 

Sustaining  Costs 

Maintenance  labor 

892 

0.00 

0.00 

Maintenance  material 

4,699 

0.02 

0.01 

Maintenance  documentation 

145 

0.00 

0.00 

Maintenance  packaging  and  transportation 

17 

0.00 

0.00 

Condemnation 

2,757,428 

9.71 

3.87 

Checkout 

1,334,975 

4.70 

1.87 

Energy  consumption 

0 

0.00 

0.00 

Supply  management 

631,282 

2.22 

0.89 

Facility  space 

7,226 

0.03 

0.01 

Recurring  training 

331,950 

1.17 

0.47 

Recurring  data  management 

21,136,406 

74.46 

29.64 

Support  equipment  maintenance 

151,028 

0.53 

0.21 

Software  maintenance 

2.031.855 

7.16 

_2^ 

$28,387,903 

100.00 

39.82 

Life  Cycle  Cost 

$71,307,003 

100.00 

C.  TOTAL  COST  OF  OWNERSHIP 

Conventional  LCC  is  just  one  element  in  determining  total  cost  of  ownership  for  an  ARPV 
processing  system.  Other  factors  such  as  catastrophic  loss  of  ARPVs  through  processing  system 
reliability  failure  should  be  considered.  The  appropriate  ARPV  attrition  rate  can  be  determined 
from  the  following  expression: 

Attrition  Rate  = 1 
where  t is  the  total  flight  duration. 

For  a 1-hour  flight  time,  the  attrition  rate  and  number  of  ARPVs  lost  in  a 10-year  period 
are  shown  in  Table  34.  This  analysis  shows  that  the  Hybrid  system  provides  minimum  total  of 
cost-of-ownership  including  both  conventional  LCC  and  costs  associated  with 
processing-system-related  ARPV  attrition. 
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tabu;  TV  ANALYSIS  OF  1)1*/M  SYSTKM  IXt  DRIVERS 


Hcrcciil  of  I’erci'iit  of 

Valiii’  Ac<|uisitioii  CosI  LCC 


Aciiuisitum  t'osls 


Ix'sigii  aiul  ilcvelopmciil 

S :,3X4,7.‘i(, 

3.91 

2.61 

Initial  livliiikal  ilata 

1, 847,750 

3.02 

2.01 

OiIr'i  MOMiccmring  cost 

128,009 

0.21 

0.14 

Ptiiue  ci-iuipment /initial  spaios  (includes 

56,487,450 

92.54 

61.71 

installation  and  tlrst  destination  costs) 

Sui>port  ei|inpnienl, /initial  spares 

197,695 

0.32 

0.22 

S6 1 ,04 1 ,560 

100.00 

66.69 

Siistaiuini>  Costs 

Maintenance  labor 

980 

0.00 

0.00 

Mainlenance  material 

7,077 

0.02 

0.01 

Maintenance  dociiinenlatiori 

219 

0.00 

0.00 

Maintenance  packa|tin{t  and  transpoitation 

25 

0.00 

0.00 

C'oiulenination 

4,170,517 

13.67 

4.56 

Cbeckoiil 

1,371,290 

4.50 

1.50 

I nergy  constiinption 

0 

0.00 

0.00 

Supply  manageineiu 

()48,454 

2.13 

0.71 

Facility  space 

7,423 

0.02 

0.01 

Recurring  training 

340,980 

1.12 

0.37 

Recurring  data  inanagenieni 

21,71 1,360 

71.18 

23.70 

Support  equipment  maintenance 

155,136 

0.51 

0.17 

Software  maintenance 

2,087.126 

6.85 

2.28 

$30,500,587 

100.()6 

33.31 

Life  Cycle  Cost 

$91,542,147 

100.00 

TABLE  34.  ARPV  AITRITION  RATE  DUE  TO  PROCESSING  SYSTEM  FAILURE 


Processing  System 

Fliglit  Critical 
MTBF  at  4S°C 
( hours) 

ARPV  Attrition  Rates 
for  1-Hour  Flight 

Number  of  ARPVs  Lost 
in  5,000  1-Hour  Sorties 

Centrali/ed 

1 .485 

0.000673 

3.36 

DP/M 

1,586 

0.000630 

3.15 

Hybrid 

1,874 

0.000533 

2.66 
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SECTION  V 

CONCLUSIONS  AND  RECOMMENDATIONS 


Of  the  three  processing  systems  described  in  Section  III  of  this  report,  the  Hybrid  system  is 
recommended  as  the  most  promising  approach  for  the  ARPV  avionics  application.  Selection  of 
this  distributed  processing  network  as  the  recommended  design  is  based  primarily  on  its  low  LCT 
compared  to  the  other  systems  considered  in  this  study.  In  addition  to  the  minimum  LCC,  the 
Hybrid  system  also  provides  the  best  system  performance  in  terms  of  flight-critical  reliability. 
Superior  flight-critical  reliability  of  the  Hybrid  system  results  from  functional  partitioning  of  the 
processing  tasks  and  from  the  natural  hardware  redundancy  which  occurs  in  the  distributed 
network  approach. 

Results  from  this  study  are  particularly  significant  in  view  of  the  current  widespread  Air 
Force  interest  in  reducing  system  LCC  through  standardization  of  hardware  and  software.  An 
important  factor  contributing  to  the  low  LCC  for  the  Hybrid  system  is  the  extensive  use  of 
standard  modules  throughout  the  distributed  processing  network.  Results  from  this  study,  in 
particular  the  modular  design  of  the  basic  PE,  should  be  widely  applicable  to  other  Air  Force 
avionic  processing  problems,  including  manned  aircraft  systems. 

In  order  to  design  specific  candidate  processing  systems,  it  was  necessary  to  postulate 
representative  ARPV  mission  scenarios  and  associated  processing  requirements.  It  is  reasonable  to 
ask  how  sensitive  the  results  of  this  study  are  to  the  assumed  scenarios  and  processing 
requirements.  Since  the  actual  ARPV  requirements  are  still  in  an  early  stage  of  definition,  there 
is  considerable  uncertainty  as  to  how  close  the  representative  processing  requirements  shown  in 
Appendix  C of  this  report  will  be  to  the  actual  requirements  ultimately  defined  for  the  ARPV. 
Reasonable  uncertainty  in  either  individual  algorithm  estimates  or  the  total  processing  estimate 
does  not  affect  the  selection  of  the  Hybrid  system  as  the  recommended  ARPV  processing  system 
design.  The  relatively  light  loading  of  the  Hybrid  system  throughput  (25  percent)  and  memory 
(65  percent)  provides  a comfortable  margin  for  accommodating  possible  increases  in  processing 
requirements.  In  the  unlikely  event  that  actual  ARPV  requirements  exceed  the  capacity  of  the 
Hybrid  system  as  currently  configured,  throughput  and/or  memory  can  easily  be  expanded  in 
small  cost-effective  modular  increments. 

As  part  of  this  program,  bus  traffic  was  analyzed  for  each  of  the  three  candidate  processing 
systems.  In  the  case  of  the  Hybrid  system,  peak  traffic  on  the  network  bus  was  determined  to  be 
approximately  *(4  kilobits  per  second,  which  represents  9.4  percent  of  the  MlL-STD-1  553A  bus 
capacity.  Again,  there  is  ample  margin  for  growth  if  the  actual  ARPV  processing  requirements 
generate  more  bus  traffic  than  the  representative  requirements  used  in  this  study.  If  bus  traffic 
problems  are  eventually  encountered,  the  Hybrid  system  can  be  modified  slightly  by  introduction 
of  “local”  buses  between  specific  PEs  or  groups  of  PEs  to  relieve  congestion  on  the  primary  or 
“global”  bus.  Both  the  global  and  local  buses  would  operate  according  to  the  requirements  of 
MIL-STD-I  553A.  At  this  time  there  does  not  appear  to  be  a need  for  high-data-rate  bus  concepts 
(e.g.,  fiber-optic  data  bus)  in  the  ARPV  application. 

For  the  life  cycle  scenario  defined  in  Section  IV  of  this  report,  acquisition  cost  for  the 
Hybrid  system  (as  well  as  the  other  systems)  was  found  to  be  the  dominant  factor  in  total  LCC. 
The  system  design  and,  therefore,  the  acquisition  cost  for  the  Hybrid  system  are  based  on 


currently  available  components  and  devices.  It  is  possible  in  the  1 981)  lime  frame  that  acquisition 
cost  can  be  reduced  through  use  of  new  components  or  devices. 

Three  specific  developments  are  expected  by  the  early  1980s  which  could  improve  the 
implementation  of  the  Hybrid  system: 

262,144-bit  nonvolatile  RAM  memory  on  a single  chip 

A microprocessor  equivalent  to  the  SBP  9900  with  user  accessible  memory  on  the  chip 

A single  LSI  chip  containing  the  digital  logic  portion  of  the  MIL-STD-1 553A  interface. 

Using  the  current  design  as  described  in  this  report,  a fully  expanded  PE  for  the  Hybrid  network 
requires  nine  4.5-  by  5.6-inch  printed  wiring  boards.  The  above  developments  could  be  used  to 
produce  a PE  of  equivalent  performance  (throughput,  memory,  and  I/O  capability)  with  only 
three  boards.  Such  a large  reduction  in  the  number  of  boards  or  modules  required  for  a full 
performance  ^E  could  have  a dramatic  effect  on  all  Hybrid  system  parameters,  including  size, 
weight,  power,  and  cost.  Also,  the  use  of  nonvolatile  RAM  memory  could  eliminate  the  need  for 
a backup  battery  power  source  in  the  Hybrid  system  design. 

Future  Air  Force  work  on  the  ARPV  processing  problem  should  include  the  development  of 
key  components  (e.g.,  the  MIL-STD-1 553A  interface  chip)  which  can  reduce  the  cost  of  the 
basic  Hybrid  system.  There  is  also  a need  for  a distributed  network  development  facility  within 
the  Air  Force  which  can  be  used  for  actual  test  and  evaluation  of  specific  distributed  processing 
configurations.  Such  a facility  could  be  based  on  currently  available  minicomputers  (T1  990 
family)  which  are  software  compatible  with  the  SBP  9900  microprocessor.  Such  a facility  would 
provide  a relatively  low  cost  way  to  accurately  measure  bus  loading,  algorithm  performance  and 
other  detailed  system  parameters  of  interest  in  the  ARPV  application.  The  minicomputer-based 
development  facility  would  be  general  purpose  in  nature  and  could  also  be  used  to  assist  in 
development  phases  of  other  Air  Force  processing  applications. 
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APPENDIX  A 

REPRESENTATIVE  ARPV  MISSION  SCENARIOS  AND  FUNCTIONS 


I.  ARPV  MISSION  SCENARIOS 

In  arriving  at  specifu;  mission  scenarios,  it  is  necessary  to  both  define  and  limit  the 
operational  environment  and  the  tasks  to  be  accomplished  by  tlie  remotely  piloted  vehicles.  The 
following  key  assumptions  were  used  in  developitig  the  three  scenarios:  one  each  for  a strike 
mission,  a reconnaissance  mission,  and  an  electronic  warfare  mission: 

1.  The  missions  will  be  performed  in  an  Kastern  European  combat  environment  involving 
NATO  and  the  Warsaw  Pact  nations. 

2.  The  ARPVs  will  perform  their  mission  in  the  presence  of  the  dense  antiaircraft 
defenses  described  in  the  Air  Force  Study  on  Defense  Suppression  (HAVE  l.IMF). 

3.  Reconnaissance  and  strike  missions  may  be  conducted  in  waves  but  each  sortie  will  be 
flown  independently  (i.e.,  no  formation  or  stationkeeping  other  than  basic  navigation!. 

4.  Active  electronic  warfare  and  chaff-dispensing  missions  will  require  .several  ARPVs  to 
operate  simultaneously  in  some  type  of  loose  formation. 

5.  Strike  and  reconnaissance  ARPVs  will  depend  upon  high  speed  and  low  altitude  for 
survival  while  conducting  single  aircraft  missions  beyond  the  FEBA. 

6.  Due  to  limited  payloads,  strike  ARPVs  will  not  have  self-protect  EW  features  such  as 
chaff  and/or  flare  dispensers  or  active  jammers. 

7.  ARPVs  which  must  penetrate  enemy  defenses  at  higher  altitudes  may  have  self-protect 
EW  features  to  aid  in  penetration  if  they  do  not  degrade  basic  EW  support  capability. 

8.  Reconnaissance  ARPVs  which  penetrate  enemy  defenses  at  low  altitude,  may  have 
self-protect  EW  features  if  they  significantly  improve  survivability. 

9.  All  sorties  will  be  preplanned  in  detail  with  no  deviations  from  the  planned  mission 
except  for  equipment  failure  or  recall,  where  this  is  feasible. 

10.  An  adequate  intelligence  data  base  on  enemy  deployment  will  be  available  for  planning 
all  strike  and  reconnaissance  missions  and  it  will  be  kept  current  using  real  or  near 
real-time  ARPV  and  manned  aircraft  reconnaissance. 

11.  Preplanned  strike  missions  will  be  primarily  against  heavily  defended  targets  at  known 
locations  and  preferably  with  acquisition  and  recognition  features  which  are  not 
dependent  upon  electro-optical  sensor  resolution  lines  oti  the  target. 

12.  Most  strike  missions  will  be  for  defense  suppression  by  knocking  air  defense  railars  off 
the  air  but  the  strike  ARPVs  will  also  be  able  to  attack  a limited  set  of  nondefense 
targets,  such  as  airfields  and  armored  columns  using  area  denial  weapons  such  as  mines 
and  other  target  activated  munittons. 

While  most  of  the  segment-  for  the  three  diffeieni  types  of  missions  will  involve  different 
functions,  there  are  several  mission  segments  which  will  be  common  to  all  missions.  These  are 
the  segments  involving  preflight  and  postflight  activities  attd  launch  and  recovery.  These  segments 
are  only  slightly  mission  dependent.  The  first  segment  is  for  ARPV  vehicle  and  equipment 
checkout  which  will  include  loading  from  storage,  the  basic  operating  programs  for  all  processors 
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iviiuirmj!  iliis.  To  Ilie  inaximuni  extent  feasible,  this  checkout  should  be  accomplished  using 
built-in  test  to  avoid  requirements  to  connect  the  ARPVs  to  external  test  equipment.  The  next 
segment  consists  of  loading  expendables  and  software  for  the  specific  sortie  to  be  accomplished 
by  the  ARPV.  This  software  will  control  all  subsequent  segments  of  the  ARPV  mission  and  will 
include  such  items  as  the  timing,  ground  track,  airspeed  and  altitude  to  be  flown  on  each 
segment,  navigation  update  checkpoints  (including  checkpoint  signatures),  equipment  operating 
instructions,  operating  frequencies,  JTIDS  data,  IFF  codes  to  be  used,  when  to  arm  weapons  and 
release  mechanisms,  when  and  where  to  operate  sensors  and  EW  equipment,  contingency 
instructions  if  applicable,  other  software  data  or  instructions  necessary  to  complete  the  mission 
and  return  to  the  recovery  control  area  and  recovery  instructions.  The  expendables  loaded  in  this 
segment  are  mission  peculiar  and  include  weapons,  sensor  film  and/or  recording  tape,  and  EW 
expendables.  Fuel  and  other  similar  aircraft  expendables  will  be  loaded  during  checkout,  if  not 
already  loaded.  Where  rocket  boosters  are  required  for  launch,  they  will  be  attached  during  the 
expendable  and  software  loading  segment. 

Ihe  next  common  segment  for  all  three  types  of  missions  is  launch  and  initial  climbout, 
including  any  ground  movement  to  get  into  launch  position.  This  movement  and  engine  start  will 
probably  be  a manual  operation  rather  than  one  controlled  by  software. 

After  engine  start,  proper  operation  of  the  engine  and  electrical,  hydraulic  and  other  engine 
subsystems  will  be  automatically  verified  by  built-in  test  and  software,  after  which  the  ARPV  is 
ready  for  launch.  Launch  may  be  by  catapult,  rocket  boost,  or  other  means  depending  upon 
ARPV  design.  In  any  event,  it  will  be  under  automatic  control  aboard  the  ARPV.  It  will  be 
initiated  on  command  from  the  local  ARPV  Launch  and  Recovery  Control  Unit  (LRCU),  which 
will  monitor  the  launch  and  climbout  and  issue  corrective  commands  to  the  onboard  automatic 
control  system  as  necessary.  Depending  upon  the  ARPV  design  and  performance,  manual 
override  of  the  automatic  flight-control  system  may  be  provided.  However,  manual  control  will 
be  of  doubtful  value,  and  even  mission  aborts  with  immediate  recovery  will  probably  have  to  be 
handled  automatically  with  suitable  software.  The  actual  abort  and  changeover  to  automatic 
recovery  would  not  occur  until  commanded  by  the  ARPV  operator.  After  launch,  an  automat- 
ically controlled  climb  profile  and  ground  path  would  be  followed.  This  would  be  monitored  by 
the  LRCU  which  would  hand  off  control  to  an  RPV  Control  and  Operations  Unit  (COU)  at  a 
preselected  location  and  time.  This  RPV  Control  and  Operations  Unit  would  have  operational 
control  of  the  RPV  throughout  the  remainder  of  its  mission  and  would  operate  under  and 
possibly  as  a part  of  the  tactical  Combat  Operations  Center  (COC), 

The  remainder  of  the  mission  under  the  COU  has  essentially  mission  peculiar  segments 
which  will  be  described  separately  for  each  of  the  three  missions.  The  COU  will  control  the 
ARPV  until  it  approaches  its  home  base  and  begins  its  descent.  At  a preselected  location,  the 
COU  will  transfer  control  to  the  LRCU  for  descent  and  recovery.  To  permit  properly  spacing  the 
returning  ARPVs,  the  ARPV  must  be  programmed  to  execute  time  adjustment  maneuvers  upon 
command.  These  maneuvers  will  include  turns  to  extend  the  approach  to  recovery  as  well  as 
orbits  and  possibly  holding  patterns.  As  with  launch  and  climbout,  descent  and  recovery  will  be 
fully  automatic  with  the  recovery  operator  being  able  to  command  changes  in  the  automatic 
system.  Recovery  will  include  automatic  engine  shutdown  after  hook  engagement,  barrier 
engagement,  or  touchdown  as  appropriate  for  the  recovery  method. 

Following  the  recovery  segment,  there  are  two  more  mission  segments  which  are  common 
to  all  three  missions.  These  are  similar  to  the  first  two  prelaunch  segments  and  are  actually 
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combined  with  them  if  the  ARl’V  is  to  be  immediately  turned  around  for  another  sortie.  Tlie 
first  postfiight  segment  includes  downloading  film  and/or  recording  tape,  check  of  all  subsystems 
using  BIT  and  AGE  test  sets  where  required,  and  a physical  exterior  inspection  for  battle 
damage.  Those  RPVs  which  are  found  ready  to  go  again  are  refueled  and  are  ready  for  the 
second  prelaunch  segment,  loading  of  expendables  and  software  for  the  next  mission.  Those 
which  are  not  ready  to  go  again  are  scheduled  for  immediate  maintenance  if  the  deficiency  can 
be  quickly  corrected  or  for  delayed  .iiaintenance  if  it  is  more  difficult  to  correct. 

A.  ARPV  STRIKE  MISSION  SCENARIO 


The  ARPV  strike  mis.sion  has  the  most  complicated  scenario,  with  more  segments  involving 
different  functions  than  the  other  two  missions,  especially  if  target  acquisition  and  weapon 
delivery  sensors  are  used.  While  many  strike  missions  can  and  will  be  conducted  by  releasing  area 
weapons  at  a measured  position  against  a target  at  a known  location,  ARPV  position  errors  and 
other  factors  may  require  target  acquisition  with  onboard  sensors  for  strike.  Since  this  latter 
mission  will  include  all  segments  of  the  strike  based  on  position  only,  plus  a sensor  target 
acquisition  segment,  the  strike  using  sensor  target  acquisition  will  be  used  for  scenario  develop- 
ment. The  segments  will  be  numbered  for  cross  referencing  the  discussion  with  Figure  A-1  which 
shows  the  mission  profile  and  Figure  A-2  which  summarizes  the  segments  and  their  sequence. 

The  first  three  segments  (numbered  1,  2 and  3)  are  checkout,  loading  and  launch  segments 
which  have  already  been  discussed.  After  launch,  the  ARPV  will  follow  a preprogrammed  climb 
schedule  and  ground  track,  which  can  be  altered  upon  command  from  the  LRCU.  Alteration  of 
the  preprogrammed  schedule  should  only  be  necessary  under  unusual  circumstances. 

At  a preselected  altitude  and/or  position,  control  will  be  transferred  from  the  RPV  LRCU 
to  the  RPV  COU  in  accordance  with  the  premission  plan  (segment  4).  The  COU  will  maintain 
control  and  monitoring  responsibility,  throughout  the  mission  until  the  RPV  reaches  its  initial 
approach  altitude  upon  return  from  the  mission.  At  that  time,  RPV  control  will  be  returned  to 
the  LRCU  for  final  approach  and  recovery  of  the  ARPV  (segments  13  and  14). 

The  ARPV  will  climb  to  the  cruise  altitude  selected  in  preflight  planning  and  maintain  this 
altitude  until  approaching  the  FEBA.  This  segment  may  involve  several  preplanned  changes  in 
ground  track  and  altitude.  During  this  segment,  which  is  over  friendly  territory,  accurate 
navigation  update  using  radio  navigation  signals  (e.g.,  GPS,  JTIDS  or  line-of-sight  DME)  will  be 
used.  As  the  FEBA  is  approached,  the  ARPV  will  make  an  automatic  descent  to  penetration 
altitude,  based  on  its  navigation  position  (segment  6).  As  penetration  altitude  of  200  to  400  feet 
is  approached,  terrain  following  will  be  initiated  using  the  radar  altimeter  and,  if  necessary, 
terrain-following  radar.  Radio  navigation  update  will  be  used  to  ensure  the  ARPV  navigation 
system  can  acquire  a checkpoint  for  navigation  update  prior  to  passing  the  FEBA.  This  will 
permit  a smooth  transition  in  the  event  enemy  jammers  disrupt  radio  navigation  signals  beyond 
the  FEBA,  either  enroute  to  or  in  the  target  area. 


Penetration  to  the  target  area  (.segment  7)  will  be  at  very  low  altitude  along  a preplanned 
ground  track.  It  will  involve  several  legs  of  varying  length  with  different  ground  tracks.  These 
will  be  based  on  such  factors  as  avoiding  known  defense  positions,  minimizing  terrain  following 
problems  and  preventing  the  enemy  from  determining  the  target  for  each  sortie.  A medium 
performance  INS  will  be  required  for  handling  some  of  the  reconnaissance  and  weapon  delivery 
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Figure  A-2  Strike  Mission  Profile  and  Numbered  Mission  Segments 


problems  of  the  ARPV  and  this  will  be  the  basic  sensor  for  following  the  ground  track.  However, 
it  will  require  frequent  position  updating  to  maintain  the  required  track  accuracy.  As  long  as  KF 
signals  can  be  received  by  the  ARPV,  this  updating  can  be  essentially  continuous  from  such 
sources  as  GPS,  JTIDS  or  special  DME  systems.  Since  these  signals  can  be  jammed  and  the 
Warsaw  Pact  countries  have  an  extensive  jamming  capability,  it  should  be  assumed  that  there  will 
be  large  areas  where  RF  navigation  signals  cannot  be  received.  These  areas  will  include  a 
minimum  radius  of  10  miles  around  major  tactical  target  complexes.  To  handle  this  situation,  an 
onboard  self-contained  navigation  update  capability  will  be  required.  It  will  probably  be  a ground 
checkpoint  update  system  using  TERCOM,  radar  map  matching,  or  an  optical  area  correlator 
using  a suitable  day  or  night  sensor.  Checkpoint  spacing  will  depend  upon  INS  drift  rate  and  the 
area  coverage  of  the  checkpoint  update  system,  but  there  will  usually  be  one  at  least  every 
10  miles.  Checkpoint  identification  data  is  part  of  the  specific  mission  data  loaded  in  segment  2. 

The  final  inbound  enroute  checkpoint  is  the  one  used  to  initiate  target  acquisition  in 
mission  segment  8.  Eor  weapon  delivery,  accurate  three-dimensional  position  is  required.  There- 
fore, this  checkpoint  will  be  selected  to  permit  vertical  position  update  using  the  radar  altimeter. 
This  checkpoint  needs  to  be  close  enough  to  the  target  so  that  INS  drift,  plus  update 
inaccuracies,  will  not  put  the  ARPV  outside  the  limits  for  weapon  delivery  based  on  INS 
position  alone  or  for  target  acquisition  using  target  acquisition  and  weapon  delivery  sensors. 
Obviously,  the  blind  delivery  requirement  is  much  more  stringent. 

Since  none  of  the  current  area  weapons  can  be  released  at  the  penetration  altitude,  pullup 
to  at  least  minimum  release  altitude  is  required  in  segment  8.  This  pullup  can  begin  over  the  final 
checkpoint.  However,  it  will  usually  be  delayed  until  a point  at  or  near  the  minimum  range 
which  will  permit  target  acquisition  and/or  weapon  delivery  maneuvers.  This  will  be  done  to 
reduce  exposure  to  enemy  air  defenses.  In  most  circumstances  the  pullup  altitude  for  the 
optimum  release  conditions  for  an  area  weapon  is  higher  than  the  minimum  release  altitude.  This 
factor,  plus  weather  and  enemy  defenses  must  all  be  considered  in  mission  planning  and  it  will 
probably  be  necessary  to  plan  and  load  several  target  acquisition  and  weapon  delivery  profiles.  If 
so,  one  would  be  the  primary  profile  to  be  automatically  used  unless  the  ARPV  operator  issued 
a command  to  do  otherwise. 

Segment  9 is  short  but  is  critical  because  its  successful  accomplishment  is  the  only  reason 
for  the  strike  ARPV  mission.  For  blind  delivery  using  position  alone,  no  target  acquisition  is 
required.  However,  for  increased  delivery  accuracy  and/or  confirmation  that  the  assigned  target 
was  attacked,  target  acquisition  by  an  electro-optical  (EO)  or  other  sensor  will  often  be  required. 
For  this,  automatic  sensor  pointing  along  the  computed  line  of  sight  (LOS)  to  the  target  (based 
on  ARPV  INS  position  and  target  coordinates)  will  be  required,  as  well  as  transmission  of  any 
required  data  to  the  ARPV  operator,  for  his  information  or  action.  With  an  EO  sensor,  operator 
action  will  almost  always  be  required  to  select  or  designate  the  target  or  aimpoint.  For  this, 
two-way  data  links  will  be  required  as  well  as  processing  to  ensure  that  ARPV  commands  are 
received  and  understood  or  for  alternate  action  in  the  event  they  are  not.  Another  processing 
problem  for  this  segment  is  whether  weapon  release  is  fully  automatic,  without  operator  input, 
and  if  automatic,  how  to  ensure  against  inadvertent  release  over  friendly  territory  in  the  event  of 
a malfunction. 

Througliout  segment  9,  the  computed  or  sensor-measured  LOS  will  be  used  for  weapon 
delivery  computations,  which,  in  turn,  will  provide  guidance  commands  to  the  ARPV  flight 


control  subsystem.  In  addition,  where  sensors  are  used,  tlie  weapon  delivery  computer  must  be 
able  to  decide  when  or  if  it  should  change  from  computed  to  measured  LOS. 

Segment  10  starts  when  the  ARPV  passes  the  weapon  release  point.  At  this  point  the  ARPV 
descends  to  the  penetration  altitude  and  begins  terrain  following  and  follows  one  of  two 
automatically  selected  preprogrammed  options.  If  the  weapon  was  not  released  for  any  reason 
other  than  malfunction  of  the  release  mechanism  after  receiving  a valid  release  signal,  the  ARPV 
will  proceed  to  an  alternate  target  and  repeat  segments  8 and  9.  This  alternate  can  be  the  original 
target  after  following  a navigation  sequence  to  bring  it  into  position  for  a second  attack.  If  the 
weapon  has  been  released,  either  on  a primary  or  alternate  target,  the  program  to  return  to  the 
FEBA  is  selected.  This  requires  following  the  programmed  ground  track  using  checkpoints  (and 
RF  navigation  when  it  becomes  available). 

On  crossing  the  FEBA  (a  navigation  position  as  far  as  the  ARPV  is  concerned)  mission 
segment  1 1 begins.  The  ARPV  updates  its  navigation  system  and  at  the  designated  position 
provides  any  required  air  defense  identification  (including  both  maneuvers  and  IFF  responses) 
and  begins  a climb  to  its  assigned  cruise  altitude.  After  crossing  the  FEBA,  RF  navigation  will  be 
used  in  segment  12.  Enemy  jamming  will  no  longer  be  effective  and  checkpoint  navigation  is 
much  less  accurate  at  higher  altitude.  A preprogrammed  ground  track  and  flight  profile  will  be 
followed  unless  the  ARPV  operator  at  the  COU  issues  program  change  commands. 

At  a preselected  range  from  the  ARPV  base,  it  will  begin  a programmed  descent  to 
approach  altitude  (segment  13)  and  control  will  be  exchanged  between  the  COU  and  the  LRCU. 
Approach  and  recovery  (segment  14)  will  be  automatic,  subject  to  LRCU  change  commands.  This 
and  segments  15  and  16  were  discussed  previously  as  common  segments  to  all  three  types  of 
ARPV  missions.  As  shown  in  Figure  A-2,  segments  15  and  16  become  segments  1 and  2 for  the 
next  mission  for  those  ARPVs  which  checkout  as  ready  in  the  postflight  check. 

Figure  A-2  shows  the  approximate  strike  mission  profile  with  each  of  the  noncommon 
segments  numbered.  Altitudes  and  ranges  are  representative  of  a typical  mission  and  will  be 
subject  to  adjustment  depending  upon  the  combat  situation,  other  air  traffic,  and  the  ARPV 
performance  versus  altitude  and  range. 

B.  ARPV  RECONNAISSANCE  MISSION  SCENARIO 

The  ARPV  reconnaissance  mission  is  similar  to  the  strike  mission  except  that  it  will  usually 
have  several  point  targets  (or  possibly  a long  strip  target)  and  may  use  more  than  one  type  of 
sensor  on  a mission.  Also,  with  sensors  which  have  wide-angle  lateral  coverage,  it  may  not  be 
necessary  for  the  ARPV  to  pull  up  to  a higher  altitude  at  the  target  and,  if  this  is  required,  the 
altitude  will  still  be  lower  than  that  for  strike  target  acquisition  or  weapon  delivery. 

Figure  A-3  provides  a reconnaissance  mission  segment  sequence  and  summary  while 
Figure  A-4  shows  a mission  profile.  For  both  figures,  the  segments  are  numbered  to  correlate  the 
mission  discussion  with  the  figures.  The  first  six  segments  are  the  same  as  those  for  a strike 
mission  and  will  not  be  repeated  here.  Also,  for  purposes  of  this  study  more  than  one  sensor  is 
assumed  for  the  reconnaissance  ARPV.  This  was  done  to  increase  the  functions  to  be  performed 
on  the  mission,  although  only  a single  sensor  will  be  used  on  most  combat  missions. 

Like  the  strike  missions  the  reconnaissance  missions  will  often  involve  several  aircraft  but 
each  sortie  will  operate  independently  of  the  others.  The  reconnaissance  and  strike  sorties  will 
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Figure  A-3.  Reconnaissance  Mission  Segment  Sequence  and  Summary 


Figure  A-4.  Reconnaissance  Mission  Profile  and  Numbered  Mivsion  Segmenti 
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probably  be  scheduled  for  penetration  past  the  FEBA  in  waves  to  complicate  the  enemy  air 
defense  problems.  Since  the  reconnaissance  sorties  operate  independently,  they  will  have  to 
depend  upon  high  speed  at  very  low  altitude  for  survival  against  enemy  air  defenses.  Thus, 
segment  number  7 will  be  flown  at  200  to  400  feet  above  ground  level.  This  will  be  accom- 
plished using  a radar  altimeter,  a terrain-following  radar  (if  necessary)  and  a ground  track 
selected  to  minimize  high  speed,  low-altitude  flying  problems.  Frequent  ground-track  heading 
changes  will  be  used  with  navigation  update  checkpoints  spaced  to  minimize  acquisition  prob- 
lems. Sensors  will  be  switched  to  standby  in  time  for  any  required  warmup  or  stabilization,  prior 
to  reaching  the  first  target. 


In  mission  segment  8,  a final  checkpoint  is  used  to  update  the  INS,  when  close  enough  to 
the  target  to  ensure  the  target  will  pass  within  adequate  lateral  distance  for  good  sensor  coverage. 
The  ground  track  is  corrected  to  pass  the  target  at  the  required  distance  for  the  desired  vertical 
or  oblique  target  imagery  and.  at  a preselected  distance  from  the  target,  altitude  is  adjusted  and 
the  sensor  turned  on.  Sensor  No.  1 is  assumed  to  be  a laser  line  scanner  designed  to  obtain 
refiectance  imagery  in  the  visible  spectrum.  The  imagery  is  stored  on  film  and  on  video  tape  if 
imagery  is  to  be  data  linked  back  to  the  RPV  control  unit. 

After  passing  the  first  target,  for  segment  9,  the  ARPV  turns  the  sensor  off,  and  descends  to 
penetration  altitude.  Using  terrain-following  and  checkpoint  navigation  update,  the  ARPV  follows 
the  preprogrammed  route  to  the  second  target.  The  video  tape  recorded  imagery  of  the  first 
target  may  be  data  linked  to  the  ARPV  control  unit  during  this  segment.  If  this  is  required, 
several  preprogrammed  options  must  be  available.  The  ARPV  will  be  programmed  to  select  and 
execute  options,  other  than  the  first  option,  only  upon  command  from  the  ARPV  operator.  The 
first  option,  which  would  be  programmed  for  automatic  execution  in  the  absence  of  an  operator 
command,  would  be  to  transmit  the  video  taped  imagery  at  normal  bandwidth  while  proceeding 
at  terrain  following  altitude  to  the  next  target.  The  second  option  would  be  a slow  readout  of 
the  taped  imagery  for  a reduced  bandwidth  transmission  for  better  antijam  performance,  if  the 
first  option  does  not  produce  satisfactory  imagery  at  the  ARPV  control  unit.  The  third  option 
would  be  the  same  as  the  second  except  that  the  ARPV  would  climb  to  a much  higher  altitude 
to  improve  transmission.  The  second  and  third  options  would  only  be  executed  upon  command 
from  the  ARPV  control  unit.  Only  at  the  control  unit  could  the  quality  of  the  received  imagery 
be  assessed  and  a determination  made  if  the  need  was  great  enough  for  the  much  higher  risk  to 
the  ARPV  of  the  higher  altitude  flight  of  option  three. 

Segments  10  and  II  of  this  mission  are  functionally  the  same  as  segments  8 and  9 except 
that  the  sensor  would  be  an  infrared  line  scanner  to  provide  radiation  imagery  in  the  8-  to 
14-micrometer  wavelength  band.  A navigation  checkpoint  near  the  second  target  would  be  used 
to  update  position  for  target  coverage  flight  path  adjustment.  The  same  options  and  constraints 
discussed  above  would  apply  to  data  linking  of  imagery  to  the  ARPV  control  station. 
Segments  12  and  13  would  also  be  functionally  the  same  as  segments  8 and  9,  including  use  of 
the  same  sensor.  These  segments  would  be  repeated  for  each  assigned  reconnaissance  point  target. 

If  the  target  were  a line  target,  such  as  a railroad  or  highway,  the  functions  would  be  the 
same  as  those  for  segments  8 and  9 except  for  navigation.  The  final  checkpoint  would  be 
selected  to  make  alignment  with  the  line  target  relatively  easy.  Also,  navigation  maneuvers  would 
have  to  be  performed  to  keep  the  ARPV  ground  track  along  the  line  target  wherever  there  are 
curves  in  the  railroad  or  highway. 
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Segment  14  starts  when  the  ARPV  passes  its  last  assigned  target  or  the  end  of  the  line 
target.  The  program  for  return  to  the  FEBA  is  selected,  the  vehicle  returns  to  terrain  following 
altitude,  and  checkpoint  navigation  is  used  to  follow  the  programmed  ground  track.  RF 
navigation  is  used  as  an  additional  navigation  input  when  it  becomes  available.  Imagery  of  the 
last  target  can  be  data  linked  to  the  control  unit  during  this  segment,  if  required.  Even  though 
data  linking  of  imagery  to  the  control  unit  is  included  in  the  functions  after  each  target,  it 
should  not  be  assumed  that  this  function  will  be  used  very  often.  There  will  be  relatively  few 
targets  where  timely  imagery  is  critical  enough  to  require  this.  For  most  ARPV  reconnaissance 
sorties,  data  linking  of  imagery  will  not  be  used.  This  will  cut  down  interference  and  bandwidth 
assignment  problems  for  the  few  sorties  which  do  require  it. 

Segments  15  through  20  are  the  same  as  segments  11  through  16  for  the  strike  mission 
which  will  not  be  repeated  here.  They  involve  identification  of  the  ARPV  on  crossing  the  FEBA, 
return  to  base,  transfer  of  control,  recovery  and  postflight  checkout  and  maintenance. 

Figure  A-4  shows  the  approximate  reconnaissance  mission  profile.  The  altitudes  and  ranges 
are  representative  of  the  expected  conditions  and  will  vary  considerably  for  each  sortie.  An 
increase  in  altitude  is  shown  over  each  target  to  emphasize  the  functions  to  be  performed. 
However,  the  navigation  accuracy  of  the  ARPV  and  sensor  V/H  capability  and  lateral  coverage 
should  be  such  that  pullup  above  penetration  altitude  should  seldom  be  necessary. 

C.  ARPV  ELECTRONIC  WARFARE  MISSION  SCENARIO 

The  electronic  warfare  (EW)  mission  has  a simpler  flight  profile  than  the  strike  and 
reconnaissance  missions.  However,  the  EW  functions  are  more  complex  due  to  the  fact  that 
several  ARPVs  are  engaged  simultaneously  in  the  same  mission,  that  they  perform  their  mission 
over  an  extended  period  of  time,  and  that  for  active  jamming,  some  options  must  be  provided 
along  with  some  means  of  controlling  the  options. 

For  mission  definition  it  is  assumed  that  each  EW  ARPV  carries  internally  the  dispenser 
mechanism  and  bulk  chaff  load  of  an  ALE-38  chaff  dispenser  pod.  It  is  also  assumed  that  the 
active  EW  equipment  consists  of  the  equivalent  of  an  ALQ-131  Jammer  and  an  ALR-46  receiver 
for  determining  threats  to  be  jammed  and  the  priority  for  each  threat. 

A typical  EW  mission  would  consist  of  laying  down  a chaff  corridor  to  cover  a multiple 
aircraft  strike  by  manned  aircraft  on  a target  at  least  50  to  100  nautical  miles  beyond  the  FEB.4 
and  providing  active  jamming  support  for  the  manned  strike  in  the  target  area. 

To  lay  down  a chaff  corridor  large  enough  and  dense  enough  to  cover  a manned  aircraft 
strike  force  will  require  at  least  four  ARPVs  dispensing  at  a rate  which  would  exhaust  their  chaff 
in  75  to  100  miles.  Thus,  two  or  more  sets  of  four  ARPVs  will  be  required  for  chaff  dispensing. 
For  an  effective  chaff  corridor,  lateral  spacing  of  the  ARPVs  must  be  controlled  so  as  to  avoid 
gaps  in  the  coverage  while  making  it  wide  enough  to  cover  the  manned  aircraft  formation. 
Along-track  spacing  is  not  as  critical  as  lateral  spacing  but  must  be  controlled  within  reasonable 
limits.  It  may  be  feasible  to  maintain  the  required  spacing  with  the  basic  ARPV  navigation 
system  using  closely  aligned  preprogrammed  flight  paths.  If  not.  some  form  of  loose  formation 
stationkeeping  wjll  be  required.  It  should  be  noted  that  when  using  DME  or  JTIDS  radio 
navigation,  relative  position  within  a loose  formation  can  be  measured.  Also,  GPS  accuracy  will 
be  more  than  enough  to  maintain  the  required  spacing  using  programmed  navigation.  Therefore. 


loose  l'omKitit)ii  spaaiii;  slioukl  only  be  a problem  when  railio  navigation  is  not  feasible  ilue  to 
enemy  jamming.  For  FW  ARPVs  operating  at  ineilium  to  high  altitude,  there  slioidd  not  be  long 
periods  when  ratlio  navigation  is  not  possible. 


Figures  A-5  and  A-6  show  the  FAV  mission  segment  sequence  and  summary  and  the  FW 
mission  tlight  profile  and  numbered  mission  segments.  1 he  segments  are  numbered  to  permit 
correlation  of  the  segments  on  the  two  figures  and  the  following  discussion  of  the  segments.  The 
discussion  will  primarily  be  about  a single  ARPV  but  the  mission  will  be  conducted  by  sets  of 
four  or  five  ARPVs.  For  the  range  shown  on  Figure  A-6.  at  least  three  sets  of  chaff  dispensing 
vehicles  will  be  required.  Ibis  is  based  on  a 75-  to  100-mile  corridor  for  each  set  and  a corridor 
at  least  240  miles  long.  The  240  miles  is  based  on  using  different  ingress  and  egress  paths  for  the 
manned  aircraft. 

I he  ARPVs  are  launched  over  a short  span  of  time  and  form  into  three  sets  based  on 
preplannetl  navigation  programs.  This  is  accomplished  during  segment  3 under  the  control  of  the 
launch  and  recovery  unit.  This  avoids  complicating  the  task  of  the  ARPV  combat  operations 
unit,  which  may  have  to  handle  several  ARPV  missions  simultaneously.  This  multiaircraft  ARPV 
mission  is  similar  to  the  single-sortie  missions  in  that  enroute  cruise  (segment  5)  and  subsequent 
segments  are  baseil  upon  programmed,  automatic  functions.  These  are  monitored  by  operators  at 
the  C'OU  but  command  inputs  to  change  programmed  actions  will  be  required  only  under 
unusual  circumstances. 

An  example  of  the  necessity  for  an  operator  commanded  input  would  be  the  corrective 
action  if  one  of  the  chaff  dispensers  fails  in  segment  6.  In  this  segment,  each  of  the  ARPV 
aircraft  is  following  a programmed  fiight  path.  However,  to  prevent  gaps  in  the  chaff  corridor 
due  to  navigation  errors,  the  ARPVs  also  monitor  relative  position  with  respect  to  the  ARPV 
designated  as  the  fiight-path  controller.  If  the  programmed  flight  paths  result  in  lateral  spacing 
being  more  than  200  to  300  feet  from  optimum,  or  the  along-track  spacing  being  off  by  more 
than  2.000  to  4.000  feet,  the  relative  position  data  is  used  to  correct  the  relative  position.  This 
will  prevent  gaps  in  the  basic  coverage  with  all  chaff  dispensers  operating  properly,  but  not  if 
one  of  them  malfunctions.  When  the  operator  receives  a signal  from  onboard  test  equipment 
indicating  malfunction  of  a chaff  dispenser,  the  other  ARPVs  do  not  receive  this  signal.  The 
operator  must  then  select  the  desired  option  to  compensate  for  the  missing  chaff.  This  will 
require  commanding  the  remaining  ARPVs  to  begin  following  optional  navigation  programs  to 
eliminate  the  gap  in  coverage.  These  optional  navigation  programs  will  already  be  stored  in  the 
navigation  computer  of  each  ARPV  and  the  operator  only  needs  to  command  a change  from  the 
primary  to  the  appropriate  optional  program.  If  there  is  a spare  ARPV  in  tin.  formation,  the 
operator  can  command  it  to  begin  dispensing  chaff  and  lly  the  flight  path  of  the  ARPV  with  the 
malfunctioning  dispenser.  In  this  situation,  the  remaining  ARPVs  do  not  make  any  changes. 

I he  first  set  of  ARPVs  performs  segments  (i  and  7 and  begins  laying  doWn  a chaff  corridor 
just  prior  to  the  FFBA  and  the  other  two  sets  of  ARPVs  follow  the  corridor.  Since  the  ARPVs 
are  flying  at  altitude,  they  use  their  active  FW  capability  to  counter  any  detected  radar  threats. 
Ihis  is  particularly  true  of  the  lead  set  which  has  no  chaff  cover.  W'hen  the  first  set  of  ARPVs 
exhausts  its  chaff,  the  second  set  assumes  the  lead  and  continues  laying  chaff.  Upon  reaching  the 
target  area  all  the  ARPVs  perforin  the  functions  of  segment  8.  They  loiter  in  the  area,  following 
programmed  flight  paths,  and  provide  active  jamming  support  against  all  assigned  threats. 

For  segment  d the  ARPVs  which  still  have  chaff  aboard  are  programmed  to  depart  the 
target  area  while  the  strike  is  in  progress  to  lay  down  an  egress  chaff  corridor.  The  remaining 
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Figure  A-S.  EW  Mission  Segment  and  Sequence  Summary 


Figure  A-6.  EW  Mission  Profile  and  Numbered  Mission  Segments 


b.  Checkout  items  when  reconfiguring  ARPV  from  EW 
to  strike  configuration. 

Remove  chaff  dispenser. 

Remove  active  jammers. 

Remove  threat  warning  subsystem. 

Remove  EW  dedicated  processors.** 

Install  weapon  handling  equipment. 

Install  weapon  delivery  (WD)  dedicated  processor.** 

Install  checkpoint  navigation  sensor  and  dedicated  processor. 

Change  processor  resident  programs. 

Remove  EW  programs. 

Read  in  WD  programs. 

Read  in  checkpoint  navigation  program. 

Read  in  weapon  handling  program  (can  be  part  of  WD  program). 

c.  Additionai  checkout  when  ARPV  is  brought  up  from  storage. 

Start  engines  and  check  out: 

Engine  data  from  idle  through  military  power 

Engine  control  response  to  command  inputs,  including  shutdown 

Hydraulic  system  performance 

Electrical  power  generation  and  control 

Flight  control  actuation  and  response  to  command  inputs. 

2.  Functions  for  Segment  2,  Load  Mission  Programs 
and  Expendables 

Load  weapons  and  check  out  interface  with  weapon  control  processor. 

Load  fuel,  oil  if  required  (no  processing  functions  required  for  this). 

Load  and  read  back  mission  program  (ground  track,  altitude  profile,  communication 
data,  equipment  operation  points,  etc.). 

Load  and  read  back  weapon  operation  program. 

Load  and  read  back  mission  weapon  delivery  program. 

Load  and  read  back  programs  for  required  options  (recall,  alternate  target,  alternate 
sensor,  alternate  route  home,  etc.). 

Load  radiation  target  data. 

Load  navigation  checkpoint  signatures. 


••If  applicable 
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ARPVs  provide  active  EW  support  for  the  manned  aircraft  wliile  these  manned  aircraft  are 
following  tlie  egress  chaff  corridor.  These  active  EW  ARPVs  will  be  programmed  to  remain 
outside  the  corridor  to  avoid  contlict  with  the  manned  aircraft.  They  will  have  navigation 
programs  which  keep  them  in  loose  formation  for  mutual  EW  protection  against  home-on-jam 
tactics. 

Upon  crossing  the  FEBA,  each  set  of  ARPVs  will  individually  perform  the  functions  of 
segment  10.  Each  set  will  be  following  a navigation  program  which  should  result  in  separate 
groups  of  four  or  five  ARPVs.  These  groups  will  be  spaced  far  enough  apart  along  track  to 
permit  recovery  of  each  group  before  the  next  is  ready  to  begin  approach  and  recovery.  If  not, 
the  combat  operations  unit  will  need  to  command  any  maneuvers  required  to  correct  the  spacing 
during  segment  1 1,  prior  to  descent  to  approach  altitude. 

Once  the  spacing  is  adequate,  each  set  of  ARPVs  descends  to  approach  altitude  and  control 
is  transferred  to  the  launch  and  recovery  control  unit  (.segment  12).  The  LRCU  monitors  the 
automatic  performance  of  maneuvers  to  separate  each  set  of  ARPVs  for  individual  recovery  and 
commands  corrections  if  necessary.  Following  this,  the  remainder  of  segments  13,  14,  and  15  are 
the  same  as  segments  14,  15,  and  16  for  the  strike  mission,  and  will  not  be  repeated  here. 

Figure  A-6  shows  a typical  flight  profile  for  an  EW  mission  with  the  flight  segments 
numbered  to  correspond  to  Figure  A-5.  The  altitudes  and  ranges  are  only  representative  values  as 
are  the  breakpoints  between  segments.  The  segments  shown  will  require  performance  of  all 
functions  likely  to  be  required  on  an  EW  mission. 

II.  ARPV  MISSION  FUNCTIONS 
A.  AVIONIC  FUNCTIONS  FOR  STRIKE  MISSION 
I.  Functions  for  Segment  1,  Checkout  RPV  and  Equipment 
a.  Normal  checkout  items 
Initialize  Processors 

Core  and  mission  processor  performance  tests 
Core  and  mission  processor  resident  program  tests 
Electronic  subsystem  tests 

Communication  subsystems 
Navigation  subsystems 
Status  monitoring  subsystem 
Electrical  power  subsystem* 

Flight  control  subsystem* 

Engine  control  subsystem* 

Vehicle  flight  configuration  subsystem.* 

* Checkout  to  extent  feasible  without  engine  running. 
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Functions  for  Segment  3,  Launch  and  Initial  Gimb 

For  catapult  launch,  attach  catapult  cable,  wheels  down. 

Verify  narrowband  data  link  (NBDL)  contact  with,  and  ARPV  control  by,  Launch  and 
Recovery  Control  Unit  (LRCU). 

Align  INS  and  acquire  GPS  navigation  signals. 

Start  engine  and  verify  normal  operation  of  electrical,  hydraulic  and  other  subsystems. 

Set  flight  configuration  for  launch  using  LRCU  and  mission  control  program  input 
commands. 

Advance  engine  to  full  power  and  activate  launch  mechanism. 

Automatic  flight  control  to  maintain  attitude  until  airspeed  and  rate  of  climb 
buildup. 

Automatic  flight  configuration  management  based  on  airspeed  and  rate  of  climb. 

When  configuration  is  clean  and  airspeed  is  adequate,  transition  to  programmed 
flight  profile  and  ground  track. 

Adjust  engine  to  climb  power  and  maintain  programmed  airspeed. 

Monitor  and  control  all  other  subsystems  on  programmed  basis  and  report  status  and 
position  over  NBDL. 

At  preplanned  enroute  point,  verify  communication  with  Combat  Operations  Unit 
(COU)  and  transfer  control  from  LRCU  to  COU. 

Functions  for  Segment  4,  Enroute  Climb 

Maintain  climb  power  and  airspeed. 

Follow  programmed  ground  track  using  INS. 

\ 

Update  INS  continuously  with  GPS  navigation. 

Monitor  and  report  position  and  status  of  all  subsystems  to  COU. 

Level  off  at  programmed  altitude. 

Adjust  to  cruise  power  when  cruise  airspeed  is  reached. 

Functions  for  Segment  5,  Enroute  Cruise 

Maintain  cruise  altitude. 

Maintain  cruise  airspeed. 

Follow  programmed  ground  track  using  INS. 

Update  INS  continuously  with  GPS  navigation. 

Establish  and  verify  operation  of  wideband  data  link  (WBDL).  Switch  to  standby  after 
verification. 

Reduce  power  and  begin  descent  to  penetration  altitude. 

Monitor  and  report  status  of  all  subsystems  to  COU. 


6.  Funclions  for  Segment  6,  Descend  to  Penetration  Altitude 

Maintain  descent  airspeed  schedule. 

Maintain  descent  power, 
l ollow  prograntined  ground  track  using  INS. 

Llpdate  INS  continuously  with  GPS  navigation. 

Switch  low-altitude  eciuipment  from  standby  to  on. 

Use  ratlar  altimeter  to  level  off  at  penetration  altitude. 

Increase  power  to  penetration  cruise  power. 

Transition  to  terrain  following. 

Update  INS  at  programmed  locations  with  checkpoint  navigation. 

Monitor  and  report  status  of  all  subsystems. 

7.  Functions  for  Segment  7,  Penetration  to  Target  Area 

Maintain  terrain  following  at  penetration  altitude. 

Adjust  power  to  maintain  penetration  airspeed. 

Follow  programmed  ground  track  using  INS. 

Update  INS  position  over  each  programmed  checkpoint. 

Switch  target  acquisition  and  weapon  delivery  sensors  from  standby  to  on. 

Switch  WBDL  to  on  and  verify  image  transfer. 

Activate  and/or  arm  weapons  and  weapon  release  subsystem  at  programmed  location  or 
time  to  go. 

Monitor  and  report  status  of  all  subsystems. 

8.  Functions  for  Segments  8 and  9,  Checkpoint  Update,  Pull  Up, 

Target  .Aaiuisition  and  Weapon  Delivery  (TA&WD) 

Maintain  terraim  following  at  penetration  altitude. 

Follow  programmed  ground  track  using  INS. 

Initiate  sensor  pointing  using  INS  and  target  position. 

Update  INS  position  over  final  checkpoint  inbound  to  the  target. 

At  programmed  distance  from  target  based  on  INS  output,  pull  up  and  follow 
programmed  profile  for  target  acquisition  and  weapon  delivery. 

Adjust  power  to  maintain  airspeed. 

Acquire  and  track  target  on  radiation  sensor. 

Switch  to  radiation  sensor  data  for  weapon  delivery  when  it  becomes  more  accurate 
than  INS  data. 

Continue  sensor  pointing  using  INS  position  or  radiation  sensor  azimuth  and  elevation. 
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Compute  three  dimensional  weapon  delivery  maneuver  commands  using  INS  and  target 
positions  and  weapon  ballistics. 

Execute  three-dimensional  weapon  delivery  computations  using  INS  and  target 
positions. 

Compute  weapon  release  points  and  after  receipt  of  operator  release  approval,  release 
weapons  when  within  proximity  limits. 

Monitor  and  report  status  of  all  subsystems. 

, 9.  Functions  for  Segment  10,  Return  to  Penetration  Altitude 

and  FEBA 

Establish  and  maintain  descent  profile. 

Adjust  power  to  maintain  descent  airspeed. 

Follow  programmed  ground  track  using  INS. 

Use  radar  altimeter  to  level  off  at  penetration  altitude. 

Increase  power  to  penetration  cruise  power. 

Transition  to  terrain  following. 

Update  INS  at  programmed  checkpoint  locations. 

Return  TA&WD  sensors  and  WBDL  to  standby. 

On  approaching  FEBA,  resume  radio  navigation. 

Monitor  and  report  status  of  all  subsystems. 

10.  Functions  for  Segments  1 1 and  12,  Transition  Past  FEBA, 

Climb  and  Enroute  Cruise 

INS  position  update  over  ground  checkpoint. 

Operate  IFF  as  programmed. 

Adjust  engine  to  climb  power. 

Follow  climb  airspeed  schedule. 

Execute  programmed  identification  maneuvers. 

Update  INS  continuously  with  GPS  navigation. 

Level  off  at  and  hold  cruise  altitude. 

Follow  programmed  ground  track  using  INS. 

Adjust  engine  to  maintain  cruise  airspeed. 

Monitor  and  report  status  of  all  subsystems. 

11.  Functions  for  Segment  13,  Descent  to  Approach  Altitude 

Follow  programmed  ground  track  using  INS. 

Continuously  uf>date  INS  using  radio  navigation. 
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Descent  and  approach  equipment  frcrn  standby  to  on.  Verify  operation. 

Reduce  power  and  follow  descent  airspeed  schedule. 

At  programmed  location,  verify  communication  with  LRCU  and  transfer  control  from 
rOU  to  LRCU. 

Transition  from  enroute  to  approach  radio  navigation  update  of  the  INS. 

Execute  programmed  delay  turns  or  orbits  upon  LRCU  command. 

Monitor  and  report  status  of  all  subsystems  to  LRCU. 

12.  Functions  for  Segment  14,  Approach  and  Recovery 

Reduce  power  and  slow  descent  rate  to  reduce  airspeed. 

Follow  programmed  approach  ground  path  using  INS  and  MLS. 

Continuously  update  INS  using  MLS  or  transition  to  MLS  for  approach  control. 

At  programmed  airspeed,  extend  landing  gear,  flaps  and  barrier  engagement  hook. 
Adjust  engine  power  to  maintain  programmed  airspeed  and  descent  rate. 

Follow  programmed  ground  track  and  flight  path  using  approach  RF  navigation. 

Use  radar  altimeter  data  as  programmed. 

Follow  airspeed,  position,  and  altitude  schedule  to  touchdown. 

Shut  down  engine  on  touchdown  or  barrier  hook  engagement. 

Turn  off  core  and  mission  equipment. 

Monitor  and  report  status  of  all  subsystems  to  LRCU. 

13.  Functions  for  Segment  15,  Postflight  Checkout 

a.  Normal  checkout  items 

Same  as  for  segment  1 . 

b.  Checkout  items  when  reconfiguring  ARPV  from  strike  to 
EW  configuration 

Remove  weapon  handling  equipment. 

Remove  WD  dedicated  processor.** 

Remove  checkpoint  navigation  sensor  and  dedicated  processor.** 

Install  chaff  dispensers  and  active  jammers. 

Change  processor  programs. 

Remove  strike  and  checkpoint  navigation  programs. 

Read  in  active-jamming  program. 

Read  in  chaff-dispensing  program. 

Read  in  navigation  program,  including  .stationkeeping. 


**lf  applicable 


14.  Functions  for  Segment  16,  Load  for  Next  Mission 


Load  chaff  and  arm  dispenser. 

Load  fuel,  oil,  etc. 

Load  and  read  back  mission  program  (ground  track,  altitude  profile,  stationkeeping  for 
chaff  dispensing,  communication  data,  equipment  operating  points,  etc.). 

Load  and  read  back  chaff  dispensing  and  active  jamming  programs. 

Load  and  read  back  programs  for  required  options  (recall,  alternate  chaff  schedules, 
alternate  routes  home,  etc.). 

B.  AVIONIC  FUNCTIONS  FOR  ARPV  RECONNAISSANCE  MISSION 
1.  Functions  for  Segment  1,  Oieck  Out  RPV  and  Equipment 
a.  Normal  checkout  Items 
Initialize  processors 

Core  and  mission  processor  performance  tests 
Core  and  mission  processor  resident  program  tests 
Electronic  subsystem  tests 

Communication  subsystems 
Navigation  subsystems 

I 

< Status  monitoring  subsystem 

' Sensor  subsystem 

j Electrical  power  subsystem* 

Flight  control  subsystem* 

Engine  control  subsystem* 

Vehicle  flight  configuration  subsystem.* 

\ j b.  Check  out  Items  when  reconfiguring  ARPV  from  EW 

\ to  reconnaissance  configuration. 

! Remove  chaff  dispenser. 

1 Remove  active  jammers, 

j Remove  threat  warning  subsystem. 

' Remove  EW  dedicated  processors.** 

I 

Install  sensor  subsystem. 

Install  checkpoint  navigation  sensor  and  dedicated  processor. 

Change  processor  resident  programs. 

Remove  EW  programs. 


•Check  out  to  extent  fe.^isible  without  engine  running. 


Kc:ul  ill  dieckpoint  n;ivi;;aiion  proiiram. 

Road  ill  s^.•ll^')^  piopiaiii,  iiu;Uuliiig  iiiiauory  transmission  roquironionts. 


r Aiiiliiioiiiil  ilu-fk.mt  wlu'ii  \RPV  is  hrou^lii  up  from  stonif^e. 

Sturt  ciifiines  and  check  out 

1 noino  data  from  idle  ihiou.uli  military  power 

linuino  ovintrol  rosponso  to  ooininaiul  inputs,  iiKludin!!  sluitdov/n 

llydraulio  s\  stout  poirorinanoo 

I'dooirical  power  tionoratioii  and  ictnlrol 

(■'light  eontml  aoliiation  and  response  to  coniniand  inputs. 

j.  t'lmotions  for  Segment  2,  t oad  Mi.ssion  Programs 
and  Fi.xpendalrles 

Load  sensor  film  and  reoording  tape  and  elteck  out  interface  with,  control  processor. 

Load  fuel,  oil  if  required  (no  processing  functions  reriuired  for  this). 

f.oud  and  read  hack  nii.ssion  progaim  (grouiui  track,  altitude  prollJe,  communication 
data,  eiiuipnient  operation  points,  etc.). 

1 oad  and  read  back  sensor  operation  program. 

Load  and  read  hack  programs  for  requi.a'd  options  (recall,  alternate  targets,  alternate 
I sensor,  alternate  route  home.  etc.). 

• ! Load  navigation  checkpoint  signatures. 

I 3.  I unctions  for  Segment  3,  Launch  aiul  Initial  Climb 

' f-'oi  catapult  launch,  attach  catapult  cable,  wlieels  down. 

v'erify  narrowband  data  link  (NBl)L)  contact  with,  and  AKPV  control  by,  Lmnch  and 
Recovery  Control  Unit  (1  RCU). 

j Align  INS  and  acquire  CPS  navigation  signals. 

> .Scarf  engine  and  verify  normal  operation  of  electrical,  hydraulic  and  other  .subsystems. 

' Set  night  configuration  for  launch  using  I RCU  and  mission  control  program  input 

, commands. 

I 

Advance  engine  to  fuli  power  and  activate  launch  mechanism. 

I Automatic  (light  control  to  maintain  attitude  until  airspeed  and  rate  of  climb 

j build  up. 

Automatic  flight  configuration  management  based  on  airspeed  and  rate  of  climb. 

When  configuration  is  clean  and  airspeed  is  adequate,  transition  to  programmed 
night  profile  and  ground  track. 

.‘Xdjiist  engine  to  climb  power  and  maintain  programmed  airspeed. 
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Monitor  and  control  all  othc:  suhsystctiiS  on  proj'ran'in'ed  basis  and  report  status  and 
position  over  NBDl  ^ 

At  preplanned  enrinife  point,  vfiity  communication  with  Combat  Operations  Unit 
(COU)  and  transfer  contro.  from  LkCU  to  CO  Li. 

4.  Functions  for  Segment  4,  Lnroute  Climb 

Maintain  climb  power  and  airspecu. 

Follow  programmed  ground  track  using  iNS. 

Update  INS  continuously  witi\  GPS  navigation. 

Monitor  and  report  positi'-n  and  status  of  ail  subsystems  to  COU. 

Level  off  at  programmed  altitude. 

Adjust  to  cruise  power  when  cruise  airspeed  is  reached. 

5.  Functions  for  Segment  5,  Enroute  Ctui;.,e 

Maintain  cruise  altitude. 

' Maintain  cruise  airspeed. 

Follow  programmed  ground  track  using  iNS. 

Update  INS  continuously  wiVu  oPS  navigation. 

Establish  and  verify  operaiion  of  wideband  data  link  (WBDl. ).  Switch  to  standby  after 
verification. 

Reduce  power  and  begin  descent  to  penetration  altitude. 

Monitor  and  repon  status  of  aii  suosysteins  to  COU. 

6.  Functions  for  Segment  6,  Hesceud  to  Penetration  ‘Mlitiide 

Maintain  destcni  airspceii  schtduie 
Maintain  de.sccnt  power. 

Follow  programmcu  ground  tiuck  using  IN'S. 

Update  INS  continuously  vrit.i  (iPS  navigation. 

Switch  low  altitude  equipment  from  standby  to  on. 

Switch  reconnaissance  sensors  from  off  to  standby. 

Use  raaar  altimeter  to  level  off  at  penetration  altitude. 

Increase  power  to  penetration  cru.se  povser. 

Transition  to  terrain  foilowing. 

Update  INS  at  programmed  locations  with  clieckpoint  navigation. 

Monitor  and  report  status  of  ali  subsystems. 


7.  Functions  for  Segment  7,  Penetration  to  Target  Area  No.  1 


Maintain  terrain  following  at  penetration  altitude. 

Adjust  power  to  maintain  penetration  airspeed. 

Follow  programmed  ground  track  using  INS. 

Update  INS  position  over  eacli  programmed  checkpoint. 

Monitor  and  report  status  of  all  subsystems. 

8.  Functions  for  Segment  8,  Checkpoint  Update,  Pull  Up,  Imagery 
Collection  for  Target  No.  I 

Maintain  terrain  following  at  penetration  altitude. 

Follow  programmed  ground  track  using  INS. 

Update  INS  position  over  final  checkpoint  inbound  to  the  target. 

At  programmed  distance  from  target  based  on  INS  output,  pull  up  and  follow 
programmed  profile  for  imagery  collection  and  recording. 

Adjust  power  to  maintain  airspeed. 

At  programmed  point,  switch  sensor  for  target  No.  1 from  standby  to  on  and  follow 
programmed  ground  track  and  profile  for  target  No.  1. 

Monitor  and  report  position  and  status  of  all  subsystems. 

9.  Functions  for  Segment  9,  Penetration  to  Target  No.  2 

At  programmed  point,  switch  sensors  to  standby. 

Establish  and  maintain  descent  profile. 

Adjust  power  to  maintain  descent  airspeed. 

Level  off  and  transition  to  terrain  following. 

Follow  ground  track  using  INS. 

Update  INS  over  each  programmed  checkpoint. 

On  command,  retrieve  taped  imagery  of  target  No.  1 and  transmit  via  WBDL. 

Monitor  and  report  position  and  status  of  all  subsystems. 

10.  Functions  for  Segment  10,  Checkpoint  Update,  Pull  Up,  Imagery 
Collection  for  Target  No.  2 

Maintain  terrain  following  at  penetration  altitude. 

Follow  programmed  ground  track  using  INS. 

Update  INS  position  over  final  checkpoint  on  inbound  leg  for  target  No.  2. 


At  programmed  distance  from  target  based  on  INS  output,  pull  up  and  follow 
programmed  profile  for  imagery  collection  and  recording. 

Adjust  power  to  maintain  airspeed. 

At  programmed  point,  switch  sensor  for  target  No.  2 from  standby  to  on  and  follow 
programmed  ground  track  and  profile  for  target  No.  2. 

Monitor  and  report  position  and  status  of  all  subsystems. 

11.  Functions  for  Segments  II,  12  and  13,  Penetration  to  Targets 

No.  3,  4,  Etc.,  Checkpoint  Update,  Pull  Up  and  Imagery  Collection 

Repeat  functions  for  segments  9 and  10  for  each  assigned  reconnaissance  target. 

12.  Functions  for  Segment  14,  Return  to  Penetration  Altitude 
and  FEBA 

Establish  and  maintain  descent  profile. 

Adjust  power  to  maintain  descent  airspeed. 

Follow  programmed  ground  track  using  INS. 

Use  radar  altimeter  to  level  off  at  penetration  altitude. 

Increase  power  to  penetration  cruise  power. 

Transition  to  terrain  following. 

Update  INS  at  programmed  checkpoint  locations. 

Return  reconnaissance  sensors  and  WBDL  to  off. 

On  approaching  FEBA,  resume  radio  navigation. 

Monitor  and  report  position  and  status  of  all  subsystems. 

13.  Functions  for  Segments  15  and  16,  Transition  Past  FEBA, 
climb  and  Enroute  Cruise 

INS  position  update  over  ground  checkpoint. 

Operate  IFF  as  programmed. 

Adjust  engine  to  climb  power. 

Follow  climb  airspeed  schedule. 

Execute  programmed  identification  maneuvers. 

Update  INS  continuously  with  GPS  navigation. 

Level  off  at  and  hold  cruise  altitude. 

Follow  programmed  ground  track  using  INS. 

Adjust  engine  to  maintain  cruise  airspeed. 

Monitor  and  report  position  and  status  of  all  subsystems. 
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14.  Functions  for  Segment  17,  De.seent  to  .\ppioach  .Altituile 


Follow  program meil  gromul  track  u.cing  INS. 

Continuously  upilate  INS  using  (Il’S. 

Descent  and  approach  equipment  from  standby  to  on.  Verily  operation. 

Reduce  power  and  follow  descent  airspeed  schedule. 

At  progiatnmed  location,  verify  communication  with  I.RCU  and  transfer  control  from 
COU  to  LRCU. 

Transition  from  enroute  to  approach  radio  navigation  update  of  the  INS, 

Execute  programmed  delay  turns  or  orbits  upon  LRCU  command. 

Monitor  and  report  status  of  all  subsystems  to  LRCU. 

15.  Functions  for  Segment  18,  .Approach  and  Recovery 

Reduce  power  and  slow  descent  rate  to  reduce  airspeed. 

Follow  programmed  approach  ground  path  using  INS  and  MLS. 

Continuously  update  INS  using  MLS  or  transition  to  MLS  for  approach  control. 

At  programmed  airspeeds,  extend  landing  gear,  flaps  and  barrier  engagement  hook. 
Adjust  engine  power  to  maintain  programmed  airspeed  and  descent  rate. 

Follow  programmed  ground  track  and  flight  path  using  approach  RF  navigation. 

Use  radar  altimeter  data  as  programmed. 

Follow  airspeed  position  and  altitude  schedule  to  touchdown. 

Shut  down  engine  on  touchdown  or  barrier  hook  engagement. 

Turn  off  core  and  mission  equipment. 

Monitor  and  report  status  of  all  subsystems  to  LRCU. 

16.  Functions  for  Segments  19  aiul  20 

Same  as  segments  1 and  2. 

C.  ELECTRONIC  WARFARE  MISSION 
1 . Functions  for  Segment  1 , Checkout  RPV  and  Equipment 
a.  Normal  checkout  items 
Initiali/.e  processors 

Core  and  mission  processor  performance  tests 
Core  and  mission  processor  resident  program  tests 
Electronic  subsystems  tests 
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Communication  subsystems 
Navigation  subsystems 
Status  monitoring  subsystem 
Electrical  power  subsystem* 

Flight  control  subsystem* 

Engine  control  subsystem* 

Vehicle  flight  configuration  subsystem.* 

b.  Checkout  items  when  reconfiguring  ARPV  from  strike  to 
EW  configuration. 

Remove  weapon  handling  equipment. 

Remove  weapon  delivery  dedicated  processors.** 

Install  chaff  dispenser  and  active  jamming. 

Install  EW  dedicated  processor. 

Remove  checkpoint  navigation  sensor  and  dedicated  processor.** 

Change  processor  resident  programs. 

Read  in  EW  programs. 

Remove  WD  programs. 

Remove  checkpoint  navigation  program. 

Remove  weapon  handling  program. 

c.  Additional  checkout  when  ARPV  is  brought  up  pom  storage. 

Start  engines  and  checkout. 

Engine  data  from  idle  through  military  power 

Engine  control  response  to  command  inputs,  including  shutdown 

Hydraulic  system  performance 

Electrical  power  generation  and  control 

Flight  control  actuation  and  response  to  command  inputs. 

2.  Functions  for  Segment  2,  Load  Mission  Programs 
and  Expendables 

Load  chaff  and  set  dispenser  controls. 

Load  fuel,  oil  if  requited  (no  processing  functions  required  for  this). 

Load  and  read  back  mission  program  (ground  track,  altitude  profile,  communication 
data,  equipment  operation  points,  etc.). 

Load  and  read  back  jammer  chaff-dispensing  schedule,  including  alternates  to  cover 
other  ARPV  losses. 

•Checkout  to  extent  feasible  without  engine  running. 

••If  applicable. 
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I o;ul  ;itul  re;ul  hack  prt)j>rains  for  required  options  (recall,  alternate  target,  alternate 
setisor,  alternate  route  home,  etc.). 

load  and  rcail  hack  programs  for  required  (light  path  adjustments  to  permit  loose 
formation  join  up  utuler  l aunch  and  Recovery  Unit  (LRCU)  control. 

3.  Functiuns  for  Segment  .1,  Launch  and  Initial  Climb 

For  catapult  launch,  attach  catapult  cable,  wheels  down. 

Verify  narrowband  ilata  link  (NBl)l.)  contact  with,  and  ARPV  control  by.  Launch  and 
Recovery  Control  Unit  (LRCU). 

Align  INS  and  acquire  (il’S  navigation  signals. 

Start  engine  and  verify  normal  operation  of  electrical,  hydraulic  and  other  subsystems. 
Set  night  contlguration  for  launch  using  LRCU  input  commands. 

Advance  engine  to  full  power  and  activate  launch  mechanism. 

Automatic  flight  control  to  maintain  attitude  until  airspeed  and  rate  of  climb 
build  up. 

Automatic  (light  configuration  management  based  on  airspeed  and  rate  of  climb. 

When  configuration  is  clean  and  airspeed  is  adequate,  transition  to  programmed 
flight  profile  and  ground  track. 

Adjust  engine  to  climb  power  and  maintain  programmed  airspeed. 

Monitor  and  control  all  other  subsystems  on  programmed  basis  and  report  status  and 
position  over  NBDL. 

Perform  programmeil  maneuvers  in  response  to  LRCU  commands  to  Join  up  in  loose 
formation  vvith  other  FW  ARPVs. 

At  preplanned  enroute  point,  verify  communication  with  Combat  Operations  Unit 
(COll)  and  transfer  control  from  LRCU  to  COU. 

4.  Functions  for  Segment  4,  Enroute  Climb 

Maintain  climb  power  and  airspeed. 

Follow  programmed  ground  track  using  INS.* 

Update  INS  continuously  with  OPS  navigation. 

Monitor  and  report  position  aiul  status  of  all  subsystems  to  COU. 

Level  off  at  programmed  altituile. 

Adjust  to  cruise  power  when  cruise  airspeed  is  reached. 

Adjust  power  as  required  to  maintain  along  track  loose  formation.** 


*hidivi(Jual  gmuiul  tracks  will  be  preprogrammed  to  provide  desired  spacing  for  dispensing  chaff  corridor. 

**Along-track  position  will  be  maintained  by  designating  one  ARPV  as  lead  aircraft.  The  other  ARPVs  will 
monitor  its  position  reports,  compare  their  along-lrack  position  with  the  lead  position  and  adjust  power  (and 
airspeed)  to  correct  along-track  position. 


104 


r 


5.  Functions  for  Segment  5,  Enroute  Cruise 

Maintain  cruise  altitude. 

Maintain  cruise  airspeed. 

Follow  programmed  ground  track  using  INS. 

Update  INS  continuously  with  GPS  navigation. 

Maintain  along-track  loose  formation. 

Increase  power  and  begin  climb  to  chaff-corridor  altitude. 

Monitor  and  report  position  and  status  of  all  subsystems  to  COU. 

6.  Functions  for  Segment  6,  Oimb  to  Corridor  Altitude  and 
Laying  Chaff  Corridor 

Maintain  climb  schedule. 

Maintain  climb  power  with  adjustments  to  maintain  along-track  loose  formation. 
Follow  programmed  ground  track  using  INS. 

Update  INS  continuously  with  GPS  navigation. 

Level  off  at  corridor  altitude. 

Adjust  to  cruise  power  when  cruise  airspeed  is  reached. 

Maintain  along-track  loose  formation. 

Switch  ALE-38,  ALR-46  and  ALQ-131  from  standby  to  on. 

At  programmed  location,  activate  ALE-38  and  begin  laying  chaff  corridor. 
Monitor  and  report  position  and  status  of  all  subsystems. 

7.  Functions  for  Segment  7,  Laying  Chaff  Corridor 

Maintain  corridor  altitude. 

Follow  programmed  ground  track  using  INS. 

Update  INS  continuously  with  GPS  navigation. 

Maintain  cruise  power  adjusted  to  maintain  along-track  loose  formation. 
Continue  chaff  dispensing. 

Report  chaff  exhaustion. 

If  programmed  to  do  so,  activate  ALQ-131  in  response  to  specified  threats. 
Monitor  and  report  position  and  status  of  all  subsystems. 


S.  Functions  ft>r  Segment  S,  Target  Area  Support  Jamming 


Maintain  coiriJor  allitiulc  anil  follow  programmed  ground  track  to  target  area. 

,\t  progiammed  location  hegin  area  jamming  following  mission  jamming  program. 
I'erform  target  area  maneuvers  using  mission  altitude  and  ground  track  program. 

,\t  programmed  time  or  location,  resume  enroute  navigation  along  egress  chaff 
corridor. 

Operate  iammer  in  accordance  with  mission  and  mission  jamming  programs. 

Update  INS  continuously  with  (IPS. 

When  t)n  target  departure  grouml  track,  adjust  cruise  power  to  maintain  along-track 
loose  formation. 

Monitor  and  report  position  and  status  of  all  subsystems. 

9.  Functions  for  Segment  9,  Return  to  F'EBA 

Maintain  corridor  altitude. 

Follow  programmed  ground  track  using  INS. 

Upilate  INS  continuously  with  C.I’S. 

Adjust  power  to  maintain  along-track  loose  formation. 

At  prograinmeil  location,  discontinue  area  jamming. 

If  programmed  to  do  sr>,  activate  ALQ-I.^I  in  response  to  specified  threats. 

.Vlonitor  and  report  position  and  status  of  all  subsystems. 

10.  Functions  for  Segments  10  and  1 1.  Transition  Past  FEBA 
and  Cruise  to  Destination 

Operate  II  F as  programmetl. 

Perform  programmed  identification  maneuvers. 

ALR-4f)  and  AL0-I3I  to  standby  or  off. 

Reduce  power  and  follow  descent  airspeed  schedule. 

Level  off  at  cruise  altitude  and  adjust  engine  to  cruise  power. 

Follow  programmed  ground  track  using  INS. 

Update  INS  continuously  with  GPS. 

Adjust  power  to  maintain  along-track  loose  formation. 

Monitor  and  report  position  and  status  of  all  subsystems. 


11.  Functions  for  Segment  12,  Descent  to  Approach  Altitude 
and  Separation  Maneuvers 

Follow  programmed  ground  track  using  INS. 

Continuously  update  INS  using  GPS. 

Descent  and  approach  equipment  from  standby  to  on.  Verify  operation. 

Reduce  power  and  follow  descent  airspeed  schedule. 

At  programmed  location,  verify  communication  with  LRCU  and  transfer  control  from 
COU  to  LRCU. 

Transition  from  enroute  to  MLS  update  of  the  INS. 

Execute  programmed  maneuvers  for  flight  separation. 

Execute  additional  programmed  delay  turns  or  orbits  upon  LRCU  command. 

Monitor  and  report  position  and  status  of  all  subsystems  to  LRCU. 

12.  Functions  for  Segment  13,  Approach,  Recovery,  and 
Postflight  Checkout 

Reduce  power  and  slow  descent  rate  to  reduce  airspeed. 

Follow  programmed  approach  ground  path  using  INS  and  MLS. 

Continuously  update  INS  using  MLS  or  transition  to  MLS  for  approach  control. 

At  programmed  airspeeds,  extend  landing  gear,  flaps,  and  barrier  engagement  hook. 
Adjust  engine  power  to  maintain  programmed  airspeed  and  descent  rate. 

Follow  programmed  ground  track  and  flight  path  using  MLS  navigation. 

Use  radar  altimeter  TFR  data  as  programmed. 

Follow  airspeed,  position,  and  altitude  schedule  to  touchdown. 

Shut  down  engine  on  touchdown  or  barrier  hook  engagement. 

Turn  off  core  and  mission  equipment. 

Monitor  and  report  status  of  all  subsystems  to  LRCU. 

Repeat  normal  checkout  items  from  segment  1. 
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APPENDIX  B 

ARPV  EQUIPMENT  AND  SIGNAL  LIST 

This  appendix  contains  the  assumed  ARPV  generic  equipment  and  associated  signal  list. 

Table  B-1  lists  the  equipment  complement  needed  for  the  various  missions  formulated  in 
Appendix  A. 

Table  B-2  is  a list  of  input  signals  required  and  output  signals  generated  by  the  equipment 
shown  in  Table  B-1.  Not  all  signals  are  required  (either  input  or  output)  and  not  all  equipment 
operates  during  all  mission  segments.  For  example,  the  IMU  operates  continuously  in  contrast 
with  the  MLS  which  operates  only  during  landing  maneuvers. 

The  column  labeled  “No.  of  Bits”  in  Table  B- 1 , indicates  the  accuracy  of  the  messages  in 
terms  of  bits.  For  example  Normal  Band  Data  Link  (NBDL)  requires  1 bit  for  power  on/off 
control,  1 bit  for  mode  set  (operate/standby),  12  bits  for  frequency  select,  2 bits  for  transmit/ 
receive  command,  N X 16  bits  for  the  messages  to  be  transmitted  (with  N the  number  of  words), 
N X 16  bits  for  messages  received,  and  less  than  16  bits  for  status  report.  Some  of  these  messages 
flow  via  the  data  bus  and  some  are  generated  internally  by  the  subsystem  service  algorithm 
assigned  to  this  particular  piece  of  equipment,  depending  on  the  architecture  considered. 


I 


TABLE  B-l.  ARPV  GENERIC  EQUIPMENT  LIST 


Mission 

Equipment 

Strike 

Recce 

EW 

NBUL(JTIDS) 

X 

X 

X 

IMU 

X 

X 

X 

GPS 

X 

X 

X 

Radar  Altimeter 

X 

X 

X 

Remote  Compass 

X 

X 

X 

Air  Data 

X 

X 

X 

MLS 

X 

X 

X 

Flight  Control 

X 

X 

X 

Engine  Control 

X 

X 

X 

IFF 

X 

X 

X 

FUR 

X 

Radiation  Sensor 

X 

Weapon  Station 

X 

Checkpoint  Update  (TERCOM) 

X 

X 

WBUL  (Video) 

X 

X 

IR  Line  Scanner 

X 

Plioto  Camera 

X 

Chaff  Dispenser 

X 

Tlireat  Warning  Receiver 

X 

Active  Jammer 

X 

TABLE  B-2.  ARPV  EQUIPMENT  SIGNAL  LIST 


Iteration  Number 


Equipment 

Signal 

in/Out 

Rate/Second 

of  Bits 

NBDLT/R* 

Power  On 

In 

1 

1 

NBDLT/R 

Mode 

In 

1 

1 

NBDLT/R 

Frequency 

In 

1 

12 

NBDLT/R 

Transmit/Receive 

in 

16 

2 

NBDLT/R 

Input  Data 

In 

16 

X 16 

NBDL  T/R 

Output  Data 

Out 

16 

X 16 

NBDL  T/R 

Status 

Out 

1 

<16 

WBDL** 

Power  On 

In 

1 

1 

WBDL 

Operate  Mode 

In 

1 

1 

WBDL 

Frequency  Band 

In 

1 

10 

WBDL 

Frequency 

In 

1 

12 

WBDL 

Antijam  Mode 

In 

1 

3 

WBDL 

Frame  Rate 
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1 

5 

WBDL 

Status 

Out  ^ 

1 

<16 

IFF 

Power  On 

In 

1 

1 

IFF 

Operate  Mode 

In 

1 

1 

IFF 

Mode  Select 

In 

4 

3 

IFF 

Code  Select 

In 

4 

8 

IFF 

Indent. 

In 

4 

1 

IFF 

Altitude 

In 

1 

12 

IFF 

Status 

Out 

1 

<16 

MLS 

Power  On 

In 

1 

1 

MLS 

Mode 

In 

1 

1 

MLS 

Frequency 

In 

1 

<16 

MLS 

DME  On/Off 

In 

1 

1 

MLS 

TC  Azimuth 

Out 

16 

16 

MLS 

TC  Elevation 

Out 

16 

16 

MLS 

TC  Range 

Out 

16 

16 

MLS 

Status 

Out 

1 

<16 

Remote  Compass 

Ex  Power  On 

In 

1 

1 

Remote  Compass 

Magnetic  Heading 

Out 

16 

12 

Remote  Compass 

■Status 

Out 

1 

<16 

IMU 

Power  On 

In 

1 

1 

IMU 

Pitch  Rate  (B) 

Out 

32 

16 

IMU 

RoU  Rate  (B) 

Out 

32 

16 

IMU 

Yaw  Rate  (B) 

Out 

32 

16 

IMU 

Pitch  Axis  Acceleration  (B) 

Out 

32 

16 

IMU 

Roll  Axis  Acceleration  (B) 

Out 

32 

16 

IMU 

Yaw  Axis  Acceleration  (B) 

Out 

32 

16 

IMU 

Status 

Out 

1 

<16 

IMU 

Acceleration  Scale  Change 

Out 

32 

8 

GPS 

Power  On 

In 

1 

1 

GPS 

Time 

In 

1 

15 

GPS 

Range 

Out 

50 

4X16 

GPS 

Range  Rate 

Out 

50 

4X16 

GPS 

Status 

Out 

1 

<16 

GPS 

Latitude 

In 

1 

9 

GPS 

Longitude 

In 

1 

11 

*Narrowband  data  Unk-transmit/receive  (JTIDS) 
**Wideband  data  link 
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TABLE  B-2.  ARPV  EOUIPMENT  SIGNAL  LIST  (Continued) 


Ei|uipmeiit 

Signal 

In/Out 

Iteration 

Rate/Second 

Number 
of  Bits 

Radar  Allimeler 

Power  On 

In 

1 

1 

Radar  Allrmeter 

Mode 

In 

1 

1 

Radar  Altmieler 

Altitude 

Out 

32 

10 

Radar  Allriitcler 

Status 

Out 

1 

<16 

t'hcckpoiiu  I'pdate 

Power  On 

In 

1 

1 

(TERCOM) 

C'lteckpoim  Llpdate 

M(.)de 

In 

8 

2 

( TLRCOM) 

Chcckpoiitt  Update 

Sensor  Activate 

In 

8 

2 

(TLRCOM) 

Clteckpotm  Update 

Checkpoint  data 

Out 

32 

4 

(TLRCOM) 

Oteckpotrit  Update 

Time 

Out 

32 

16 

(TLRCOM) 

Clicckpoirrt  Update 

Status 

Out 

1 

<16 

(TLRCOM) 

Air  Data 

Power  On 

In 

1 

1 

■Air  Data 

Total  Temperature 

Out 

4 

8 

Ait  Data 

Total  Pressure 

Out 

4 

11 

Air  Data 

Static  Pressure 

Out 

4 

II 

Air  Data 

Status 

Out 

1 

<16 

Llttrlrt  Coittrol 

Power  On 

In 

1 

1 

Lltgltt  Control 

Elevator  Movement 

In 

32 

9 

Flight  Control 

Aileron  Movement 

In 

32 

9 

Flight  Control 

Rudder  Movement 

In 

32 

9 

Flight  Control 

Status 

Out 

1 

<16 

Lngine  and  Lngine 

Power  On 

In 

1 

1 

Control 

Lngine  and  Lngine 

Throttle  Position 

In 

16 

8 

Control 

Engine  and  Lngine 

RPM 

Out 

16 

8 

Control 

Lngine  and  Lngine 

TOT 

Out 

4 

8 

Control 

Engine  and  Lngine 

POP 

Out 

4 

8 

Control 

Lngine  and  Engine 

Overheat 

Out 

4 

1 

Control 

Lngine  and  Engine 

Fuel  Pressure 

Out 

4 

8 

Control 

Lngine  and  Lngine 

Fuel  Flow 

Out 

4 

8 

Control 

Engine  and  Lngine 

Status 

Out 

1 

<16 

Control 

ChalT  Dispenser 

Power  On 

In 

1 

1 

Chaff  Dispenser 

Mode 

In 

1 

1 

Chaff  IXspenser 

Type  Dispenser 

In 

1 

1 

Chaff  Dispenser 

Pulse  Rate 

In 

1 

8 

Chaff  Dispenser 

Pulse  Interval 

In 

1 

8 

Chaff  Dispenser 

Chaff  Exhausted 

Out 

1 

1 

Chaff  Dispenser 

Status 

Out 

1 

<16 

TABLE  B 2.  ARPV  EQUIPMENT  SIGNAL  LIST  (Continued) 


Iteration  Number 


Equipment 

Signal 

In/Out 

Rate/Second 

of  Bits 

FLIR  and  Gimbal 

Power  On 

In 

1 

1 

FLIR  and  Gimbal 

Mode 

In 

1 

2 

FLIR  and  Gimbal 

Gimbal  Store 

In 

4 

1 

FLIR  and  Gimbal 

LOS  Point 

In 

4 

1 

FLIR  and  Gimbal 

Azimuth  Angle 

In 

16 

13 

FLIR  and  Gimbal 

Elevation  Angle 

In 

16 

12 

FLIR  and  Gimbal 

FOV  Select 

In 

4 

4 

FLIR  and  Gimbal 

Gain 

In 

4 

2 

FLIR  and  Gimbal 

Focus 

In 

4 

2 

FLIR  and  Gimbal 

Reticle 

In 

4 

2 

FLIR  and  Gimbal 

Cooling 

Out 

1 

1 

FLIR  and  Gimbal 

Not  Ready 

Out 

1 

1 

FLIR  and  Gimbal 

Standby 

Out 

1 

1 

FLIR  and  Gimbal 

Operate 

Out 

1 

1 

FLIR  and  Gimbal 

Status 

Out 

1 

<16 

FLIR  and  Gimbal 

Azimuth 

Out 

4 

6 

FLIR  and  Gimbal 

Elevation 

Out 

4 

6 

Radiation  Sensor 

Power  On 

In 

1 

1 

Radiation  Sensor 

Mode 

In 

1 

3 

Radiation  Sensor 

Break  Lock  Comm. 

In 

4 

1 

Radiation  Sensor 

Target  Azimuth 

In 

4 

6 

Radiatic  . Sensor 

Target  Elevation 

In 

4 

6 

Radiation  Sensor 

Operator  Mode 

Out 

1 

2 

Radiation  Sensor 

Type  Detected 

Out 

1 

6 

Radiation  Sensor 

Type  Acquired 

Out 

1 

6 

Radiation  Sensor 

Target  Azimuth 

Out 

4 

6 

Radiation  Sensor 

Target  Elevation 

Out 

4 

6 

Radiation  Sensor 

Status 

Out 

1 

<16 

IR  Line  Scanner 

Power  On 

In 

1 

1 

IR  Line  Scanner 

Mode 

In 

1 

2 

IR  Line  Scanner 

V/H  Ratio 

In 

4 

7 

IR  Line  Scanner 

Contrast 

In 

1 

2 

IR  Line  Scanner 

Roll  Angle 

In 

8 

7 

IR  Line  Scanner 

Drift  Angle 

In 

4 

6 

IR  Line  Scanner 

Lateral  Angle 

In 

1 

4 

IR  Line  Scanner 

Film/Tape  Remaining 

Out 

1 

8 

IR  Line  Scanner 

Status 

Out 

1 

<16 

Photo  Camera 

Power  On 

In 

1 

1 

Photo  Camera 

Mode 

In 

1 

1 

Photo  Camera 

V/H 

In 

4 

7 

Photo  Camera 

Film  Remaining 

Out 

1 

8 

Photo  Camera 

Roll  Angle 

In 

8 

7 

Photo  Camera 

Drift  Angle 

In 

4 

6 

Photo  Camera 

Lateral  Angle 

In 

1 

4 

Photo  Camera 

Status 

Out 

1 

<16 

Weapon  Station  and 

Power  On 

In 

1 

1 

Weapon 

Weapon  Station  and 

Mode 

In 

1 

1 

Weapon 

Weapon  Station  and 

Master  Arm 

In 

1 

1 

Weapon 

Weapon  Station  and 

Weapon  Arm 

In 

1 

4 

Weapon 
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TABLE  B-2.  ARPV  EQUIPMENT  SIGNAL  LIST  (Continued) 


Equip  UKnt 

Signal 

In/Out 

Iteration 

Rate/Secund 

Number 
of  Bits 

Weapon  Station  and 

Release  Quantity 

In 

1 

3 

Weapon 

Weapon  Station  and 

Release  Interval 

In 

1 

4 

Weapon 

Weapon  Station  and 

Release  Enable 

In 

1 

1 

Weapon 

Weapon  Station  and 

Release  or  Fire  and  Time 

In 

16 

12 

Weapon 

Weapon  Station  and 

Retarded/Nonretarded 

In 

1 

1 

Weapon 

Weapon  Station  and 

Select/Salvo  Jettison,  Weapons 

In 

4 

4 

Weapon 

Weapon  Station  and 

Select/Salve  Jettison,  Racks 

In 

4 

4 

Weapon 

Weapon  Station  and 

Ground  Interlock 

in 

1 

1 

Weapon 

Weapon  Station  and 

Store  Type 

Out 

1 

6 

Weapon 

Weapon  Station  and 

Weapon  Ready 

Out 

1 

1 

Weapon 

Threat  Warning 

Radar  Characteristics 

Out 

16 

48 

Threat  Warning 

Power  On 

In 

1 

1 

Threat  Warning 

Band  Select 

In 

1 

3 

Threat  Warning 

Threshold  Adjust 

In 

4 

6 

Threat  Warning 

Threat  Logic  Select 

In 

4 

4 

Threat  Warning 

Mode 

In 

1 

1 

Threat  Warning 

Status 

Out 

1 

<16 

Active  Jammer 

Power  On 

In 

1 

1 

Active  Jammer 

Mode 

In 

1 

1 

Active  Jammer 

Transmit  On/Off 

In 

1 

1 

Active  Jammer 

Transmit  Indication 

Out 

4 

1 

Active  Jammer 

Band  Select 

In 

1 

4 

Active  Jammer 

Jam  Mode  Select 

In 

1 

4 

Active  Jammer 

Status 

Out 

1 

<16 

Miscellaneous 

Oil  Pressure 

1 

6 

Miscellaneous 

Oil  Quantity 

I 

4 

Miscellaneous 

Fuel  Quantity 

1 

8 

Miscellaneous 

Gear  Up  and  Locked 

1 

2 

Miscellaneous 

Flap  Position 

1 

4 

Miscellaneous 

Flap  Control 

1 

4 

Miscellaneous 

Speed  Brake  Position 

1 

1 

Miscellaneous 

Speed  Brake  Control 

1 

1 

Miscellaneous 

Gear  Down  and  Locked 

1 

2 

Miscellaneous 

Weight  on  Gear 

1 

1 

Miscellaneous 

Pilot  Heat  On/Off 

1 

1 

Miscellaneous 

Fuel  Dump 

1 

1 
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APPENDIX  C 

ARPV  ALGORITHMS  AND  PROCESSING  REQUIREMENTS 

From  the  assumed  ARPV  Mission  Functions  and  Equipment  (Appendix  A and 
Appendix  B)  estimates  can  be  made  regarding  algorithm  and  processing  requirements.  Since  tlie 
ARPV  is  not  totally  defined,  these  estimates  are  of  relative  certainty  rather  than  of  absolute 
confidence. 

In  order  to  have  a good  representation  of  the  total  computational  power  onboard  the 
aircraft,  and  for  the  purpose  of  projecting  its  application  in  the  1980  time  frame,  tasks  of 
relatively  high  processing  requirements  were  chosen.  For  the  purposes  of  this  study,  processing 
requirements  (memory  and  throughput)  were  found  in  existing  documentation  for  a number  of 
tasks.  For  other  tasks,  the  processing  requirements  were  estimated  using  engineering  judgment.  In 
general,  the  ARPV  processing  load  was  overestimated  in  order  to  simulate  worst  case  conditions. 

Each  algorithm  has  the  following  requirements  associated  with  it: 

Instruction  memory  (permanent)— PROM 

Data  Memory  (temporary)- RAM 

Throughput  depending  on  instructions  executed  and  iteration  rate. 

Within  the  numbers  describing  the  above-mentioned  characteristics,  10  percent  was  added  for  the 
built-in  test  (BIT)  requirement.  Three  categories  of  algorithms  were  considered; 

Computational-In  this  category  the  main  purpose  of  the  algorithm  is  to  provide 
numerical  data  needed  by  each  function.  Solution  of  equations  or  manipula- 
tion of  data  mathematically  is  included  in  this  category 

Logical —These  algorithms  are  used  mainly  in  decision  making,  table  reading  and 
packing  or  unpacking  binary  data.  Required  executive  functions  are  also 
included  in  this  category'. 

Subsystem  Service  (SSVC)-These  are  equipment-dependent  algorithms  and  their 
only  function  is  to  control  hardware  operation  and  procedures  (mode  set, 
power  on/off,  input/output,  scaling,  etc.). 

A list  of  algorithms  under  each  category  is  given  below: 

Computational 

INS  (Strapdown) 

Navigation  Filter 

GPS 

Steering 

Flight  Control 

Air  Data 

Guidance 

MLS 

Line-Of-Siglit  Computation 
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St;itus  NKtiiiloi 
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Active  J.iminer  ( onliol 

SSVC 

Ravkii  Altimeter 
Natfovvhaikl  Data  Link  (NBDL) 

111 

Bulk  Storage 

Aireratt  Instrumentation 

II.IR 

Rarliation  Sensor 
Wideband  Data  Link  (W'BDL) 

Weapon  Station 
IR  lane  Seamier 
I’lioto  Camera 
Cli.iri'  Dispenser 
Threat  Warning  Receiver 

Whenever  a computational  or  logical  algorithm  interfaces  directly  with 
'uhsvstem  (sensor/actuator),  an  allowance  was  made  to  accommodate  the  SSVC 
1 liese  cases  are; 

I.NS 

IMD  linertial  measurement  unit) 

Remote  compass 

(IRS 

(il’S  Receiving  System 
I light  Control 
I ngme 
Actuators 
^lr  Dat.i 

All  Dat.i  Sensor 


I lb 


an  external 
requirement. 


MLS 

MLS  Receiver  System 
TERCOM 

TERCOM  Sensor 
Active  Jammer  Control 

Active  Jammer  Transmitter 

Table  C-1  shows  the  ARPV  processing  requirements  with  the  respective  iteration  lates. 

f'igure  C'-l  shows  a block  diagram  for  a representative  strapdown  inertial  navijiation  system. 
The  procedure  used  to  obtain  memory  and  throughput  requirements  for  such  an  algorithm  is 
illustrated  in  Figures  C-2  through  C-11.  The  number  of  add/subtract  and  multiply  divide  opera- 
tions is  counted.  For  those  operations  the  assumption  is  made  that  there  is  a need  for  three 
housekeeping  instructions  per  arithmetic  operation.  In  the  course  of  the  actual  navigation 
computation,  various  trigonometric  functions  are  required,  e.g.  sine,  cosine,  and  tangent.  (Jne 
special-purpose  subroutine  is  needed  for  matrix  transpositions  which  involves  the  logical  manipu- 
lation of  indices.  Some  of  the  trigonometric  subroutines  and  the  matrix  transposition  are 
executed  more  than  once,  which  contributes  a factor  of  instruction  iteration  equal  to  the 
number  of  repetitions.  The  results  of  this  general  process  are  summarized  in  Tables  C-2  and  C-3. 

For  IMU  subsystem  service,  the  memory  estimate  is  200  words  for  instructions  and 
50  words  for  data.  The  BIT  estimate  is  200  instructions  (usually  10  percent  of  total  tested 
algorithm  instructions)  and  50  data. 

Following  this  independent  study  of  the  strapdown  inertial  navigation  algorithm,  a 
comparison  was  made  between  other  existing  studies  (Table  C-4).  A final  judgment  was  made, 
giving  3,500  words  of  memory  and  65  KOPS  throughput  requirement. 


TABLE  C l.  ARPV  PROCESSING  REQUIRLMKNIS 
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Kate/Second 
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Memory 
16- Bit 
Words 

Data 
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16  Bit 
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Total 
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( ore 

l''S  (s::a(i'juwii  • 

,12 

3.000 

500 

3.500 

63 
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1 ,300 
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‘.a’S 

l/'(>4 

1 1 ,.S00 

2,100 
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1 1.5 
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75 
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16 
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15 

< ill' J ii’.v’e 
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1,050 
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32 

550 
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1,050 
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iFL  SSVC 

4 

150 

20 

170 

0.5 

Hob  Cuiurol 

32 

1,000 

2,000 

3,000 

30 

Bulk  Stoiage  SSVC 

16 

50 

20 

70 

0.5 

Air.  rail  iiislturnenlation  SSVC 

1 

70 

30 

100 

0.5 

Mission  Specific 

Une -of-iight  Compulation 

16 

330 

50 

380 

5 

laigcM  Hosition  Coinputaiion 

16 

3.30 

50 

380 

5 

Impact  Point  Computation 

16 

1,760 

200 

1,960 

71 

LLIK  SSVC 

16 

600 

100 

700 

3 

Kailiation  Sensor  SSVC 

4 

600 

iOO 

700 

2 

I 1 RCOM 

32 

2,450 

2,000 

4,450 

70 

VVidebaiKi  Data  Link  SSVC 

1 

170 

50 

220 

0.5 

Weapon  Station  SSVC 

16 

550 

100 

650 

3 

IR  lane  Scanner  SSV'C 

8 

220 

50 

270 

1 

Photo  Camera  SSVC 

8 

220 

50 

270 

1 

1 Halt  Dispenser  SSVC 

1 

330 

60 

390 

1 

Thieal  Warning  RCVR  SSVC 

16 

400 

100 

500 

1.5 

Active  Jammer  Control 

16 

880 
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1 ,080 
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Figure  C-2.  Equation  for  Angle  Rate  Computation 


cO|,  ojj,  CO,  = Angular  rates  of  vehicle  body  frame  relative 
to  stabilized  frame 

di-  d2-  da  - da  “ Quaternion  elements  which  specify  body 
frame  relative  to  stabilized  frame 

a = (coi^  + t02  ^ + W3^)  At^ 


a/4 

coi  At 

-CO2 

-C03  At 

cOi  At 

a/4 

CJ3  At 

-t02  At 

(jJ  2 

< 

3 

1 

a/4 

to  1 At 

CO3  At 

CO2  At 

-to,  At 

a/4 

Figure  C-3,  Quaternion  Update 
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Ajcelemmelers 


ajj  = Elements  of  A matrix  computeii  Irom 
quaternion  elements 

vl/,  0,  0 = Conventional  yaw,  piteh  roll  of  A C boJv  axes 
with  respect  to  stahili/ed  frame 


‘hi  ‘>23 
t>32  <*33 


di  ^ -43^  -44^  -<4243  4i44  I -'4244  -*  4.43  t 


-<4243  +4.  44  » 4.^  42^  +43^  + 44*  -'4344  4i42> 


-(4244-4.43  > -'4344  +4. 42  1 4i‘  42^  43*  + 44^ 


V 


'(2) 

. 0 = sin'‘^a,,2  j 


0 = tan 


Figure  C-4.  “A”  Matrix  Computation 


"xB'  "yB'  "rB  ” Sensed  accelerations 

A^,  Ay,  A,  = Sensed  accelerations  resolveil  along  stabilized 
frame  axes 


— — 

— — — — 

^xB 

A , 

= 

‘*vB 

3yB 

^zB 

Ay 

‘*yH 

Figure  C-5.  Acceleration  Transformation 


li  - j k,  tli|,  III  + \',  [ At 


■Vdl  ♦ 


+ lit,  ) (Ah  + 

I,V  + :s2/  I 0 (a^x  ^ > • '^'y  f^y 

(/J-,  + lils,  ) (p  ^ ) 0 g. 


li  - SiiuiothcJ  vertical  altitude  of  vehicle 
liii  = Haiumctnc  allitude 

V\  , Vy , \\  ■-  Linear  velocities  ol  vehicle  with  respect  to 
earth  along  stahili/ed  t'raine  axes 

ily . i2,  - l arlli-rate  components  along  stabilized  axes 
g\  ■ g>  • g\  ~ (Iravity  components  along  stabilized  axes 
Kj  . kj  = Altitude  feedback  loop  gains 


Figure  C 6.  Linear  Velocity  Computation 


Rp  = I iarth’s  polar  radius 
K|  - Larth’s  eipiatorial  radius 
f = I '2d7  coefficient  of  nattenine 


cjj  = Llements  ol  direction  cosine  matrix  specifying 
vehicular  position  relative  to  earth 


Ml  f(l  3 C\,^  (2  I'Cm 

R,  R,  " ' R,. 

R,'  i'  R,  ' " ^ ^ ^ r|  ^ " 

, ^12  I’v  ( 21 

" I C,,=  ‘ =■' 


Figure  C 7 I’osition  Matrix  Computation 
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Si  = Earth  rate 


C 


Figure  C-8.  Earth  Rate  Computation 


Initial  Position 


<i>(0),  M0),aj(0) 


Cn  = cos  a-p  cos  X - sin  aj  sin  <J>  sin  X 
Cj2  = — sin  a-j-  cos  X - cos  ay  sin  4>  sin  X 
Ci3  = cos  <I>  sin  X 
Cji  = sin  tti-  cos  4> 

C22  = cos  a-r  cos  <P 
C23  = sin  4> 

Csi  = — cos  a-j-  sin  X — sin  a-y  sin  4>  cos  X 
C32  = sin  a-j-  sin  X-  cos  ctj  sin  <1)  cos  X 
C33  = cos  <I>  cos  X 


-Py  0 


X=lan“' 


Or  = tan  ' - 


<t>  = Latitude 
X = Longitude 

j = Wander  angle  with  North  of  stabilized  frame.  (Zero  for  North-oriented  system) 
Figure  C-9.  Cosine  Matrix  Update 


(1-2 1 

' Rk 


CV) 


g„  = Gravity  constant  = 9780.270  X ICT*  km/sec^ 
e = Eccentricity  of  a meridianal  ellipse  on  the  earth 
Figure  C-10.  Gravity  Computation 
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Figure  C-11.  Arithmetic  Operations  Ket|uired  for  .Angle  Rate  Computation 


TABLE  C 2.  INERTIAL  NAVIGATION 
MEMORY  REQUIREMENTS 


Memory  Words 


Function 

Instructions 

Data 

Arithmetic  and  Housekeeping 
Operations 

1787 

250 

IMU  Subsystem  Service 

200 

50 

BIT 

200 

50 

Total 

2187 

350 

TABLE  C-3.  INERTIAL  NAVIGATION  PROCESSING  REQUIREMENTS 


Instructions  Total  Instruction  Iterations 


Function 

Mul./Div. 

Add/Sub. 

Other 

.Mul./Div. 

Add /Sub. 

Other 

Inertial  Navigation 

251 

144 

1185 

251 

144 

1185 

Computation 

Trigonometric 

36 

18 

108 

108 

54 

324 

Subroutines 

Matrix  Transpose 

_ 

45 

_ 

— 

90 

Subroutine 

Total 

287 

162 

1338 

359 

198 

1599 

1787 

Total  Operations  = 

2156 

Average  Throughput  Requirement 

= 2156  operations  X 32  iterations/second 
= 68.9  KOPS/second 


Instruction  Mix: 

M/D  - 17  percent 
Other  — 83  percent 


TABLE  C4.  INERTIAL  NAVIGATION-COMPARISON  WITH  OTHER  ESTIMATES 


Source 

Memory 

(Words) 

Throughput 

(KOPS/Second) 

TI-ARPV 

2537 

68.9 

TI-DAIS 

2417 

45.6 

Rockwell-ARPV 

3000 

40.0 

Iloneywell-DP/M 

2550 

33.3 

Judgment 

3500 

65 
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APPENDIX  D 

SUMMARY  OF  SYSTEM  NETWORK  SIMULATOR  (SNS)  RESULTS 
I.  DISCUSSION  OF  SNS  RESULTS 

This  appendix  contains  a summary  ol  simulation  runs  using  the  1)1’  M System  Network 
Simulator  (SNS).  Three  candidate  avionic  system  configurations  were  simulated: 

Centralized  System 
Hybrid  System 
DP  M System. 

Note  that  the  System  Network  Simulator  used  to  sinuilale  tire  AkPV  configurations  was  a 
modified  version  of  the  SNS  delivered  to  AF.AL  as  part  ot  Contract  F3361 5-’’4-( -101 S. 
Distributed  Processor  .Memory  .Architectures  Design  Program.  The  latter  SNS  was  designed  for 
the  recommended  PH  architecture  in  the  subject  study  and  the  executive  and  bus  models  w'ere 
designed  accordingly. 

In  the  .ARPV  application,  the  .MlL-STD-1  553A  protocol  was  used  for  the  TD.M  bus.  The 
earlier  study  used  the  round-robin  method  for  the  TDM  bus.  The  bus  model  tor  the  .AKPV 
application  had  to  be  modified  to  simulate  the  MlL-STD-1  553A  protocol.  .Also,  the  executive 
models  for  the  original  SNS  specifically  modeled  the  executive  for  the  earlier  recommended 
architecture.  In  the  ARPV  application,  these  models  should  be  looked  upon  as  general-purpose 
with  no  meaningful  input  to  the  executive  loading  statistic  for  each  PH  in  the  simulation 
summary  reports. 

A brief  description  is  provided  of  the  changes  that  were  made  to  existing  SNS  subroutines 
to  simulate  the  .ARPV  avionic  system  configurations.  Using  the  Hy  brid  system  as  an  example,  a 
listing  of  the  user  input  data  is  provided  in  Table  D-1.  The  meaning  of  each  variable  used  in  the 
user  input  data  set  is  the  same  as  defined  in  the  description  of  the  original  SNS. 

The  only  major  change  maue  to  the  SNS  was  to  the  bus  transmit  models:  GBL'SCX  and 
LBUSCX.  The  round-robin  passing  of  control  mechanism  in  both  models  was  removed.  .Message 
formats  as  dictated  by  MlL-STD-1 553A  are  shown  in  Figure  D-1.  The  statistics  collection 
statements  of  the  bus  models  were  modified  to  correct  for  the  resulting  changes  in  time 
measurements. 

The  follow'ing  conventions  were  established  for  user  data: 

Message  types  for  terminal-to-terminal  transfers  shall  be  100  < type  <200 
Message  types  for  bus  controller-to-terminal  transfers  shall  be  type  <100. 

.A  simplifying  assumption  was  made  for  the  Centralized  configuration.  Since  all  terminals  except 
the  computer  are  “dumb"  terminals,  there  are  no  terminal-to-terminal  transfers.  The  following 
variable  was  defined  to  differentiate  between  the  centralized  and  the  distributed  configurations: 

A named  common  “CONFIG”  was  defined  with  a logical  variable  ARCHIT  as  a 
member.  CONFIG  was  defined  in  MAIN  and  in  LBUSCX  and  GBUSCX.  ARCHIT 
is  set  .FALSE,  in  MAIN  when  simulating  centralized  configurations  and  TRUE,  in 
MAIN  for  distributed  type  configurations.  This  variable  impacts  statistic  collec- 
tions in  the  various  configurations. 
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TABLt  l>l  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION 


uninnnniu  lunmtiniiii  3333333333333933 

ITT9P 
X 9 1 2 E > 2 
G*PTME«?, 

9ITP«D»1  . 

PSYMC«P 
4EN0 
»TDEEN 
T*SKIP  * 1 
4EHD 

S«TB0 

NUI"MSG  ■ t 

»EnO 

SPDEF»J 
TYPE  » 31 
length  ■ 1 
NUP0E9  ■ 1 
TASKIO  • 41 
CClEn  « 

»ENn 

4TDEFN 

TASKin  a 2 

send 

4HT60 

NUMMSG  a 1 
SEND 
SHOEFN 
TYPE  a 22 
length  a 1 
NUHDES  a 1 
TASKIO  ■ 42 
CCLEN  a 21^ 

SFNn 
STDEFN 
TASKID  • 3 
SEND 
SMTBO 

NUHMSG  » 1 
send 
SMr.FFN 
TYPE  a 23 
length  a 1 
NUMOE9  a 1 
TASKID  a 43 
CClEn  a 2'A 

send 

STOEFn 
TASKID  a 4 
NPPEO  a t 

send 

SHTPC 
NUHHSG  a 
SEND 
STDEFn 
TASKID  a 5 
SEND 


TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


»MT80 

NUHMS6 

kEND 

IMOEFN 

TYPE 

LENGTH 

NUHOES 

T*$K10 

cclen  ■ 

tENO 

kTOEFN 

TtSKlO 

tENO 

• HTBO 

NUHHSG 

lEND 

•MPEFN 

TYPE 

length 

NUH0E8 

TkSKIO 

CCLEN  ■ 

lENP 

kTOEPN 

TASKIO 

tENO 

tHTBO 

NUHHSG 

tENO 

tHOEPN 

TYPE 

length 

NUHOES 

TtSKIO 

cclen  ■ 

tENO 

tTOlPN 

TtSKIO 

tENO 

tHTBO 

NUHHSG 

tENO 

tHOEPN 

TYPE 

length 

NUHOES 

TtSKXO 

CCLEN  ■ 

tENO 

tTOEPN 

TtSKXO 

tENO 

tHTBO 

NUHHSG 

lENO 

tHOEPN 

TYPE 

length 


■ t 


■ ?3 

■ 1 

■ t 

• 43 

291 


■ S 


• t 


■ 28 

• 1 

■ I 

■ 46 


• 7 


■ \ 


■ 27 

■ 1 
• 1 

■ 47 

2P 


■ S 


• 1 


• 28 

■ 1 

• \ 

• 4B 

2« 


• 0 


■ 1 


• 29 

• t 


TABLE  U 1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


NUMDES  • 

1 

T*SKI0  » 

49 

CCLITN  ■ 

&ENO 

T4SKI0  ■ 

10 

(END 
(MT90 
NUNMSG  ■ 

1 

SEND 
(MOEEN 
TYPE  » 

3D 

LENGTH  ■ 

1 

NUMOES  » 

1 

T*SKID  • 

SD 

CCLEn  b 

(END 
(TDEFN 
TASKIO  » 

11 

SEND 
(MTBD 
NUHHSG  ■ 

1 

(END 
(MDEFN 
TYPE  » 

31 

LENGTH  a 

1 

NUHDES  a 

1 

T4SKI0  a 

51 

CCLEN  a ; 

?D 

SEND 
stoefn 
T*SKI0  a 

12 

(END 

(MTeo 

NUHHSG  a 

1 

send 

(MDEFN 
TYPE  ■ 

32 

length  a 

1 

NUHDES  a 

1 

T*SKI0  a 

52 

CCLEN  a : 

2D 

send 

(TDEFN 
TASKID  a 

13 

(ENP 

(HT0O 

NUHHSG  a 

1 

(END 
(MOEFn 
TYPE  a 

33 

length  a 

1 

NUHDES  a 

1 

TASKID  a 

33 

CCLEn  a 

2D 

(End 

(TDEFN 
TASKIO  a 

14 

TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


acNo 

tMTBO 


NUHMSC  ■ 

SEND 

IhOCFN 

1 

TYPE  • 

34 

LENGTH  • 

1 

NUhOES  ■ 

1 

TASKIO  ■ 

94 

CCLEN  ■ : 

GEND 

JTDEFN 

TA9KID  ■ 

SEND 

tHTBO 

IS 

NUHMSG  ■ 

BEND 

BMOEPn 

1 

TYPE  ■ 

39 

length  ■ 

t 

NUHOES  ■ 

1 

TiSKIO  ■ 

99 

CCLEN  ■ : 

send 

BTOEFN 

ZH 

TASKIO  ■ 

BEND 

BHTBD 

18 

NUHHSG  ■ 

BEND 

BHUEFN 

1 

TYPE  a 

38 

LENGTH  a 

1 

NUMDES  a 

1 

TASKIO  a 

56 

CCLEN  a ; 

BCNO 

BTDEFN 

Z" 

TASKIO  a 

BENO 

BMTBO 

IF 

NUHHSG  a 

bend 

BHDEFN 

1 

TYPE  a 

37 

LENGTH  a 

1 

NUHOES  a 

t 

TASKIO  a 

97 

CCLEN  a ; 

BENO 

BTOEEN 

20 

TASKIO  a 

41 

TNAHE  a 

BTYPI  a 

iSP 

XTXHE  a 

197 

NPREO  a 

1 

NXH86  a 

1 

XHTYPE  a 

21 

TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Conlinued) 


NUMSUC  ■ I 
SfflO  ■ 39 
aENo 
»MTB0 

NUMMSG  ■ 2 

»EN0 

tHDEFN 

TYPE  • 112 
LENGTH  ■ 1 
NUH0E9  » 1 
TASKIO  a 48 
CCLEN  a 20 
SENQ 
»MOEFN 
TYPE  a t 
length  ■ 1 
NUHDES  a t 
TASKIO  a 4 
CCLEN  a 2(K 
(END 
STOEFn 
T*SKIO  a 42 
TNAHE  a 40H  INS 
RTYPE  a 35«0 
XTINE  a 2B313 
NPREO  a 1 
NIHSG  a 1 
IMTYPE  a 22 

send 

»HT80 

NUHHSG  a 3 

tEND 

tHOEFN 

TYPE  a IPP 

length  a 18 
NUHDES  a I 
TASKIO  a 38 
CCLEN  a 2n 
»ENC 
tHOEFN 

TYPE  a lai 
LENGTH  a 18 
NIIMOES  a 1 
TASKIO  a S3 
CCLEN  a 28 

send 

tHOEFN 

TYPE  a 182 
length  a 18 
NUHOES  a 1 
TASKIO  a 49 
CCLEN  a 2« 
tENO 
tHOEFN 

TYPE  a 183 
length  a 12 
NUHOES  a 1 
TASKIO  a 51 


TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


ccifN  ■ 
iENO 
»M0EPN 
TYPE  • 3 

length  ■ 1 


NUHCES  • 1 
T*SK10  • 4 
CCiEN  • 2<i 
IEnP 


iTi'.EPN 
T*SKI0  ■ 
Tn*H£  • 

•Type  ■ 

XTIHE  ■ 

npred  ■ 

nImSG  ■ 
IMTYPE  ■ 


43 

40H  RADIATTON  SENSOR 
7291 
628 
1 
1 

23 


&ENC 

NUmHSG  ■ 9 

sen') 

»H  Vf fN 

TY?F  ■ 31P 
LENETM  ■ ? 
NU:-iOES  • 1 
TASkIO  ■ 84 
CC'„EN  ■ 2« 
aEnd 
tMOfPN 


TYPE  • 3 
LENGTH  • 1 
NUnOES  • I 
TASKIO  ■ 4 
CCLEN  ■ 2«) 

send 

ATpEFN 

TASKIO  a 45 

TNAME  a 4PH  air  OATA 

RTrPE  a 633 

XTIHE  a 1875 

NPREO  a 1 

NIHSG  a 1 

IHTYPE  a 23 

NUMSJC  a 1 

SRIO  a 33 

»ENO 

»HT80 


NUHHS6  a 2 

»ENC 

SHOEPN 


TYPE  a 3P7 
length  a 3 
NLHOES  a 1 
TASKIO  a 43 
CCLEN  a 26 
SEND 
SHOEEN 
TYPE  a 3 
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TABLE  U-l.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


length  ■ 1 
NUHOES  • t 
TASKin  a 4 
CCLEN  a 2n 
»EN0 
ITDEEN 
TASKID  a 46 

TNAMC  a 40M  STATUS  MONITOR 

RTYPE  a insn 

XTIME  a 93B 

NPRED  a 1 

NJMSG  a 1 

IMTVPE  a 26 

»ENO 

iMTBO 

NUMHSG  a 2 

*ENP 

»M0EFn 

Type  a 113 
length  a 23 
NUHOES  a I 
TASKIO  a 47 
CCLEN  a 2« 

»EN0 

»M0EFN 

type  a 6 
length  a 1 
NUHOES  a 1 
TASKIO  a 4 
CCLEN  a 2P 
lENO 
•TDEEN 
TASKIO  a 47 

TNAME  a 4PH  narrow  BANO  QATA  LINK 

RTYPE  a 1P5P 

XTIME  a 93B 

NPREO  a 2 

NIHSG  a 2 

IMTYPE  a 27,113 

send 

»HTB0 

NUMHSG  a 1 
lENO 
»M0EFN 
TYPE  a 7 

length  a 1 

NUHOES  a 1 
TASKIO  a 4 
CCLEN  a 26 
SENO 
STOEPN 
TASKIO  a 46 

TNAME  a 4PH  TARGET  POS.  COHP, 

RTYPE  a 38P 

XTIME  a 1383 

NPRED  a 2 

NIHSG  a 2 

IMTYPE  a 28,112 


TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


NUHSUC  • 1 
SRIO  ■ 49 
aCND 
4HTB0 

NUMHSG  ■ 1 

tENO 

tHOEPN 

TYPE  • 8 

LENGTH  • 1 

NUHOES  ■ 1 

T*SKI0  ■ 4 

CCLEN  ■ 28 

tENO 

»TOEFN 

TASKID  ■ 49 

TNAME  ■ 40M  impact 

RTYPE  ■ t96« 

XTIME  ■ 22188 
NPRED  ■ 3 
NIHSG  ■ 2 
IMTYPE  • 29,188 
&ENO 
aHTBO 

NUHMSG  a 2 

aENO 

aNDEFN 


TYPE  a IH 
LENGTH  a 1 
NUHOES  a 1 


TASKin  a 94 
CCLEN  a 28 

aENC 
aHDEFN 
TYPE  a 9 


LENGTH  a t 
NUHOES  a 1 
TASKID  a 4 
CCLEN  a 20 


COhP. 


aENO 

aTOEFN 

TAS4IO  a 92 

TNAME  a 48H  NAV. 

RTYPE  a 3680 

XTIME  a 8 

NPRED  a 2 

NIMSG  a 2 

IMTYPE  a 38,188 

aENO 

aHTBO 

NUMMSG  a 1 


aENO 
aMOEFN 
TYPE  a 10 
LENGTH  a 1 
NUHOES  a 1 
TASKIO  a 4 
CCLEN  a 28 
aENO 


ftlter 
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TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Conlinjed) 


trOEFN 

TiSKID 

TNAHE 

BTTPC 

XTlHE 

K'PRED 

N1HS6 

IhTYPE 

SEND 

J“TB0 

NUPMSG 

SEND 

aHOEPM 

TYPE 

LENGTH 

NUMOES 

TASKIO 


31 

4PH  flight  control 

33SP 

14P63 

2 

9 

31.1F3 


1 


11 

1 

1 

4 


CCLEn  ■ 99 

SEND 

4T0EEN 

T4SKI0  ■ 32 

TNAHE  ■ 4PH  steering 

RTYPE  ■ 77P 

XTIPE  ■ 3594 

NPREO  ■ t 

NIM8G  • 1 

IPTYPE  ■ 32 

send 

»MT80 


NUHHSG  a 2 

send 

iHOEEN 

TYPE  a 308 
length  a S 
NUPOES  a 1 
T4S4I0  a 31 
CClEN  a 2P 
ieno 


8H0EFN 

TYPE  a 12 

length  a 1 

NUPOES  a 1 

T4SKI0  a 4 

CClEn  a 2P 

• END 

8TCEEP 

TASain  a 33 

TNAME  a 4MH  GUIOANCE 

•TYPE  a 2SB« 

ITIPE  a 2188 
NPREO  a 4 
NIPSG  a 2 

IHTYPE  a 33.1PI 

ieno 

tPTBO 

NUHHSG  a 1 

send 

•hOEEn 
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TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


TYPE  ■ 13 
tENGTH  ■ 1 
NUMOES  ■ 1 
TASKIO  ■ 4 
CCLEN  ■ 20 
lEMO 
ftTOEFN 
TASKIO  ■ 94 

TNAME  ■ 40H  mission  control 

RTYPE  • 9300 

XTImE  • 46S8 

NPREO  ■ 2 

NIMSC  ■ a 

IMTYPE  ■ 34,144 

SENO 

IHTBO 

NUMMSG  • 4 

lENO 

SMOEFm 

TYPE  ■ 111 

length  ■ a 

NUMOES  ■ 1 
TASKIO  ■ 9S 
cclen  ■ a0 
SEnO 
SHOEPN 

TYPE  • 119 
LENGTH  ■ a 
NUMOES  ■ 1 
TASKIO  ■ 97 
CCLEN  ■ 20 
SENO 
SHOEPN 

TYPE  ■ 319 
length  a 2 
NUMOES  a 1 
TASKIO  a 99 
CCLEN  a 20 
SENO 
SMOEPn 
TYPE  a 14 
length  a 1 

NUMOES  a 1 
TASKIO  a 4 
cclen  a 20 
SENO 
STOEFN 
TASKIO  a 99 

TNAME  a 40H  WIOE  RANO  DATA  LINK 

RTYPC  a 220 

XTIME  a 197 

NPREO  a 1 

NIMSG  a 1 

IMTYPE  a 39 

SENO 

SMTBO 

NUMMSG  a 1 
SENO 
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TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE^ 
STRIKE  CONFIGURATION  (Continued) 


•HOCFN 
TYPE  • 15 

length  ■ 1 

NUMOES  • 1 
TASKID  ■ 4 


CCLEN  I 

•end 

»TDEFN 

T4SKI0 

THAME 

RTYPE 

XTIME 

HPREO 

HI  MSG 

ihtype 

SEND 

AMTBO 

NUHMSG 

tEHO 

SMOEFN 

TYPE 

LENGTH 

NUMOES 

TASKin 

CCLEN  • 

lENO 

•TOEFN 

LAST  ■ 

TASKIO 

TNAME 

RTYPE 

XTIME 

HPREO 

NIMSG 

IMTYPE 

SEND 

IMT80 

NIIMMSG 


58 

4PH  FLIR 
70P 
93S 
2 
2 

36,111 


» 1 


• 18 

• 1 
• 1 
• 4 

28 


.TRUE. 

• 37 

■ 40H  WEAPON  STATION 

■ 658 

■ 036 

« 2 

■ 2 

■ 37,113 


SEND 
ftMOEFN 
TYPE  • 17 
LENGTH  ■ 1 
NUMOES  • 1 
TASKIO  • 4 
CCLEN  ■ 28 
SENO 
SGBOEF 
TOTPE  ■ 9 

G6CL  • 1,2, 3, 4, 3, 8, 7, 8, 2 

BLGTH  ■ 9 

• ENO 

SLBDEF 

NUMPE  • 1 

PECON  ■ 1 

BlGTH  ■ 1 

send 

SLBOEF 
NUMPE  ■ 1 
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TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


PECON 

SLGTH 

tENO 

4UBOEP 

NUMPC 

PECOn 

BLGTM 

bend 

BLBOEP 

NOhPE 

PECfiN 

BLGTh 

BEND 

BLBOEF 

NUHPE 

PECON 

BLGTH 

bend 

aUBOEP 

NUMPE 

PECON 

BLGTH 

BEND 

BLBOEF 

NUMPE 

PECPN 

BLGTH 

BEnO 

BLBOEF 

NUMPE 

PECON 

BLGTH 

BEND 

BLBOEF 

LiSTe 

NUMPE 

PECON 

BLGTH 

bend 

BOEFINE 

PEIO 

NUMTSK 

TASKS 

BENO 

BOEFINE 

PEIO 

NUMTSK 

TASKS 

bend 

BOEFINE 

PEIO 

NUMTSK 

TASKS 

beno 

BOEFINE 

PEIO 

NUMTSK 

TASKS 


2 


3 


4 


s 


B 


7 


8 


.true. 

1 

9 


7 

,2, 3, 4, 9, 8, 7, 8, 9, 10, 11, 12, 13, 14, IS, 16. 17 


2 

1 

42 


3 
9 

41.49.46,92.93,94 

4 

2 

47,90 
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TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


(ENO 
SDEEINE 
PEID  • 
NUMT8K  ■ 
TASKS  • 
SEND 
tOEFINE 
PEIO  • 
NUHTSK  ■ 
TASKS  ■ 

send 

iOEFiNE 
PEtO  • 
NUMTSK  ■ 
TASKS  ■ 

send 

SOEFINE 
PEIO  ■ 
NUPTSK  a 
TASKS  a 
SEND 
SOEFIPE 
PEIC  a 
NUPTSK  a 
TASKS  a 
LASTa 
SEND 

sfndefn 

10  a 

BUNT  a 
ITEB  a 
NUPPE  a 
SFPE  a 

send 

AFNOEFN 
10  a 

RUNT  a 
ITER  a 
NUPPE  a 
SFPE  a 

send 

SFNOEFN 
10  a 

RUNT  a 
ITER  a 
NUPPE  a 
SFPE  a 
SEND 
SFnOEFN 
ID  a 

RUNT  a 
ITER  a 
NUPPE  a 
SFPE  a 

send 

IFNOEFN 
10  a 

RUNT  a 


9 

I 

91 


6 

3 

49,48,A9 


T 

1 

97 


9 

t 

99 


Q 

1 

99 

.TRUE. 


1 

IflPP 

3129P 

1 

3 


2 

2RP9 

3129P 

1 

3 


3 

3000 

2900P0 

1 

9 


9 


4000 

290000 

1 

3 


9 

9000 
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TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 


XTE« 

■ 

itiepppp 

NUHPE 

■ 

1 

8EPE 

• 

3 

iEno 

iFNDEPM 

ID 

• 

7 

RUNT 

« 

60PP 

ITER 

• 

829PR 

NUMPE 

s 

J 

SFPE 

• 

4 

IfNC 

ifndefn 

ID 

■ 

8 

RUNT 

■ 

797IR 

ITER 

■ 

825eP 

NUNRE 

■ 

1 

8FPE 

• 

8 

IENO 

EPNOEPN 

ID 

• 

9 

RUNT 

■ 

2139P 

ITER 

■ 

82899 

NUMPE 

m 

1 

8PPE 

m 

8 

lEND 

EFNOEPN 

ID 

• 

10 

RUNT 

• 

2235P 

ITER 

■ 

2900929 

NUMPE 

■ 

1 

8FPE 

• 

4 

tEND 

8FN0EFN 

ID 

• 

11 

RUNT 

s 

23399 

ITER 

■ 

31299 

NUMPE 

• 

1 

8FPE 

• 

9 

IENO 

8FN0EFN 

ID 

s 

12 

RUNT 

■ 

26199 

ITER 

■ 

82999 

NUMPE 

9 

1 

SFPE 

9 

3 

8EN0 

»FN(JEFN 

ID 

13 

RUNT 

28790 

ITER 

290000 

NUMPE 

1 

8FPE 

3 

(END 

(FNDEFN 

ID 

9 

14 

RUNT 

9 

42800 

ITER 

9 

82909 

NUMPE 

9 

1 
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TABLE  D-1.  HYBRID  SIMULATION  TEST  CASE- 
STRIKE  CONFIGURATION  (Continued) 

SFPE  • 3 
lEND 
tFNOEFN 
10  • 19 

BUNT  ■ 4739B 

ITE9  ■ lanonKin 

NUMPE  ■ 1 

SPPE  ■ 9 

ftENO 
4FN0EFN 
10  ■ 16 
RUNT  « 484n«i 
ITER  ■ 629PR 

NUMPE  ■ 1 
SFPE  ■ R 
*EnO 
&FN0EFN 
in  ■ 17 
RUNT  ■ 4949R 
ITER  ■ 8250P 
NUNPE  • 1 
SFPE  ■ 7 
L*ST«  .TRUE. 
send 


^ 

TABLE  D-2.  ALGORITHM  SIGNAL  LIST 

No.  of 

No.  of 

Msg. 

Msg. 

Msg, 

Size  Iteration/ 

Algorithm 

In  Origin 

Out 

Destination  X 16  BITS  Second 

Mission  Control 

2 Weap.  Slat. 

1 

2 

Weap.  Slat. 

4 

1 

Weap.  Slat. 

16 

8 

Weap.  Slat. 

1 

3 

IFF 

1 

3 

IFF 

4 

4 

MLS 

1 

3 

NBDL 

1 

2 

NBDL 

16 

Nxln  NBDL 

16 

6 

WBDL 

1 

1 

Rem.  Comps. 

1 

1 

IMU 

1 

2 

INS 

1 

1 

GPS 

1 

2 

Rad.  Alim, 

1 

1 

Air  Data 

1 

1 

TERCOM 

1 

1 

TERCOM 

4 

2 

TERCOM 

8 

1 

Fit.  Coni. 

1 

1 

Fit.  Com. 

1 

2 

FLIR 

1 

6 

FLIR 

4 

2 

Rad.  Sen. 

1 

1 

Rad.  Sen. 

4 

2 

Gnd  Trk.  Guidance 

1 

1 

Ter.  Following 

1 

3 

Climb/Desc. 

4 

Guidance 

1 

INS 

4 

3 

INS 

32 

NS 

2 Mis.  Con. 

1 

2 Rem.  Comps. 

16 

1 Mis.  Con. 

4 

1 IMU 

32 

3 IMU 

32 

3 Mis.  Con. 

32 

q 

Guidance 

32 

9 

Nav.  Fill. 

32 

9 

Impel.  Pnl. 

32 

3 

LOS 

32 

TABLE  M l.  ALGORITHM  SIGNAL  LIST  (Continued) 


No.  of 

No.  of 

Msg. 

Ms". 

Msg. 

Size 

Iteration/ 

' Algorithm 

In 

Origin 

Out 

Destination 

XI6  BITS 

Second 

Navigation  Eiltei 

4 

INS 

32 

9 

INS 

1/2 

(iiiidaiice 

n (a)  (irouiiJ  I iacking  Mode 

1 

INS 

■> 

4 

i 

4 

Mis.  Con. 

2 

4 

I 

1 

INS 

1 

1 

1 

1 

Steering 

1 

1 

1 (h)  Ten  am  Following  Mode 

1 

Rad.  Alim. 

1 

32 

1 

*> 

INS 

1 

32 

1 

Mis.  Con. 

1 

32 

1 

Steering 

1 

4 

(c)  ('limb/Dcbcend  and  Cruise 

2 

Air  Data 

1 

1 

Vertical  Mode 

2 

INS 

1 

1 

3 

Mis.  Con. 

1 

1 

1 

Steering 

1 

1 

1 (d)  Weapon  Delivery 

4 

INS 

1 

16 

5 Vertical  Mode 

3 

Impct.  Pnt. 

1 

16 

1 

J 

1 

Steering 

1 

4 

[ j (e)  Weapon  Delivery 

1 

INS 

1 

16 

1 i Horizontal  Mode 

2 

Impct.  Pnt. 

1 

16 

1 1 

1 

Steering 

1 

4 

1 (1)  MLS  Guidance  Mode 

3 

MLS 

1 

16 

1 ' 

1 

INS 

1 

16 

1 

1 

Steering 

1 

4 

1 Air  Data 

1 

Mis.  Con. 

1 

1 

. 

1 

Stat.  Mon. 

1 

1 

3 

Guidance 

1 

4 

3 

Fit.  Cont. 

1 

4 

3 

Air.  Dt.  Sen. 

I 

4 

i i f'-PS 

8 

GPS  Rcvr. 

2 

32 

1 ' 

6 

Nav.  Fill. 

2 

1/64 

i 

1 

Mis.  Con. 

1 

1 

1 

Stat.  Mon. 

1 

1 

IFF  SSVC 

1 

Mis.  Con. 

1 

1 

1 

Stat.  Mon. 

1 

1 

Radar  Altimeter  SSVC 

2 

Mis.  Con. 

1 

1 

1 

Stat.  Mon. 

1 

1 

I 

1 

Guidance 

1 

32 

• 

1 

Tgt.  Pos. 

1 

32 

TABLE  D-2.  ALGORITHM  SIGNAL  LIST  (Continued) 


Algorithm 

No.  of 
Msg. 
In 

Origin 

No.  of 
Msg. 
Out 

Destination 

Msg. 

Size 

X16  BITS 

Iteration/ 

Second 

TERCOM 

1 

Mis.  Con. 

1 

Stat.  Mon. 

1 

1 

1 

1 

2 

Mis.  Con. 

1 

8 

3 

Nav.  Fill. 

1 

4 

Mli> 

4 

Mis.  Con. 

1 

3 

Stat.  Mon. 
Guidance 

1 

1 

1 

1 

1 

16 

Target  Lme-i>t'-Sighi 
Computation 

1 

3 

Mis.  Con. 
Mis.  Con. 

1 

s 

1 

32 

3 

INS 

2 

32 

2 

Rad.  Sens. 

2 

32 

Radiation  Sensor  SSVC 

1 

Mis.  Con. 

1 

Stat.  Mon. 

1 

1 

1 

1 

2 

LOS  Comp. 

2 

32 

2 

Tgt.  Pos.  Com. 

2 

32 

Target  Position  Computation 

1 

2 

Mis.  Con. 
Rad.  Sens. 

1 

T 

1 

32 

3 

Impct.  Pnt. 

2 

32 

Impact  Point  Computation 

1 

3 

Mis.  Con. 

Tgt.  Pos.  Com. 

1 

T 

1 

32 

9 

INS 

2 

32 

2 

Air  Data 

1 

4 

3 

Guidance 

s 

32 

Flight  Control 
(and  Engine  Control) 

6 

INS 

2 

32 

3 

Steering 

2 

16 

3 

Air  Data 

1 

4 

2 

Mis.  Con. 

2 

Stat.  Mon. 

1 

1 

1 

1 

1 

Steering 

2 

16 

Steering 

3 

Guidance 

2 

4 

4 

Fit.  Cont. 

2 

16 

Wideband  Data  Link  SSVC 

6 

Mis.  Con. 

1 

Stat.  Mon. 

1 

1 

1 

1 

Narrowband  Data  Link  SSVC 

3 

1 

Mis.  Con. 

1 

Stat.  Mon. 

1 

1 

1 

1 

16 

1 

N 

(Any) 

1 

16 

M 

(Any) 

1 

16 
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TABLt  0-2.  ALGORllMM  SIGNAL  LIST  (Coiiliiiuedi 


Algoridim 

No.  of 
Msg. 
Ill 

Origin 

No.  of 
\kg. 
Out 

Destination 

Msg. 

Size 

X16  BITS 

Iteration/ 

Second 

11  IK 

> 

Mis.  Con. 

1 

1 

> 

l.OS  Comp. 

■> 

,?2 

(> 

Mis.  Con. 

5 

Slal.  Mon. 

1 

1 

4 

1 

Mis.  Con. 

1 

4 

Sl.iUls  Moillloi 

K 

Is  Subsyst  « 

1. 

NBDL 

1 

1 

1 

to 

1 

Mis.  Con. 

1 

1 

We.ipon  .Station  .SSV'C 

N 

1 

Mis.  Con. 
Mis.  Con. 

1 

1 

1 

1(1 

2 

Mis.  Con. 

•> 

Slat.  Mon. 

1 

1 

4 

1 

CTuiK  Dispenser  SSVC 

4 

Mis.  ( on. 

•> 

Slal.  Mon. 

1 

1 

1 

1 

riueat  Warning  RCVR. 

SSVC  .t 

s 

Mis.  Con. 
Mis.  Con. 

1 

1 

1 

4 

1 

Act.  Jam. 

2 

1(1 

1 

Stat.  Mon. 

1 

1 

.Active  Jammer  Control 

2 

Mis.  Con. 

1 

Mis.  Con. 

1 

1 

1 

4 

1 

Sta(.  Mon. 

1 

1 

IR  l ine  Scanner  SSVC 

,s 

Mis  Con. 

1 

1 

1 

(iuiilance 

1 

4 

Jl 

INS 

"A 

Stat.  Mon. 

•> 

1 

32 

1 

hiolo  Camera  SSVC 

Mis.  Con. 

1 

1 

1 

(iiiidance 

1 

4 

INS 

■> 

Slal.  .Mon. 

•> 

.32 

If  .1  t.isk  executes,  but  the 

next  scheduled  time 

to  begin 

goes  beyond 

the  simulated  time. 

till’  iiK'ss.mc  11)  slionkl  bi.’  '>T00  unless  a prcUecessor-sucecssor  relationship  exists  with  another 
task.  The  niessaees  in  Table  l)-2  also  aeeount  Tor  eases  where  identieal  pieces  oT  inToTmation  have 
dilTerent  destinations.  Certain  messages  denoted  as  NxIN  or  KxlN  are  determined  by  the  nature 
oT  ei|uipment  such  as  Narrowband  Data  l ink  when  the  exact  number  of  words  is  not  known  at 
this  point.  The  upper  bouiuiarv  m this  case  is  .^2  words  loni!  per  MlL-STD-i  553A. 

Table  D-3  contains  the  ililTerent  modes  of  the  Ciuidance  algorithm,  the  input  signals 
required  (IN)  .nui  signals  generated  (OUT).  Table  D-2  shows  the  CTuidance  signal  How  (incoming 
and  outgoing)  in  I'urther  detail,  separated  into  its  dilTerent  modes. 

Tigiire  l)-2  shows  the  summary  ol'  the  bus  tralTic  results  Tor  all  three  configurations,  during 
the  weapon  delivery  segment  of  the  strike  mission.  The  bus  tral'llc  summary  shows  total  bus 
traTl'ic  in  KHI’S  and  .ilso  divideil  into  percentages  utilized  for  data,  overhead,  and  gap.  The  sync 
percentage  is  shown  as  zero  due  to  the  assumption  of  20  bits  per  word  to  include  the  required 
s\  nc. 
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• GAP  EQUALS  5 MICROSECONDS 

Figure  D-1.  Message  Formats  for  MIL-STD-1SS3A  Data  Bus 


For  the  Centralized  configuration  a user-defined  “trick”  was  utilized  to  simulate  this  case 
within  the  constraints  of  the  SNS  executive  models.  The  central  computer  was  defined  as  PE  10 
and  assigned  all  the  processing  load.  The  bus  controller  (which  would  normally  be  resident  inside 
the  computer)  was  defined  as  PE  1 and  connected  to  PE  10  by  a local  bus. 

Other  operations  of  the  ARPV  simulator  are  the  same  as  in  the  original  SNS. 

The  lengths  of  the  messages  are  determined  by  the  number  of  generated  output  words  from 
a particular  algorithm.  For  example,  the  Air  Data  algorithm  generates  three  pieces  of 
information:  true  airspeed,  angle  of  attack,  and  altitude.  Therefore,  the  message  length  is  three, 
assuming  single-word  precision.  If  double  precision  were  assumed,  the  message  length  would  be 
six. 

If  this  message  has  multiple  destinations,  the  output  queue  should  have  as  many  messages  as 
there  are  receivers,  with  different  IDs  (over  100  if  the  message  is  required  and  over  300  if  the 
update  is  not  necessary).  If  only  one  of  the  generated  data  words  is  required  by  one  of  the 
receivers,  the  message  length  should  be  adjusted  accordingly.  If  the  receiving  task  is  collocated  in 
the  same  processing  element  with  the  transmitting  task,  the  message  is  not  accounted  for,  since 
there  is  no  bus  transfer. 

Table  D-2  summarizes  the  number  of  messages  flowing  between  the  assumed  algorithms  as 
well  as  their  size  (precision  required  in  terms  of  16-bit  words)  and  iteration  rate  of  message 
generation. 
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CENTRALIZED  SYSTEM- STRI KE  CONFIGURATION 


************  t**0»**if»**'**  t*'******vm*mtfmm*^**  ******1**  4 

BUS  TRAFFIC  CECCMPQSITION  FOR  GLOFAL  BIS  <59 


TOTAL  TRAFFIC 
TRAF=IC  UTILIZEO  FCR  CATA 
TRAFFIC  UTILIZED  FCR  HEADER 
TRA'^FIC  U’’ILIZE0  FCR  SYNC 
TRAFFIC  UTILIZED  FCR  GAP 


39.65  KBPS 
24 .BO  KBPS 
13.20  KBPS 
0.0  KBPS 
1.65  KBPS 


62.55  PERCENT 
33.29  PERCENT 
0.0  FEPCEKT 
4.16  PERCENT 


*4  v«««« 4 4*4  4*41*  4 *«r* 4 ************  4*44*4«444i4i4  4*44t4  44  4 4 4»4  44  44 


HYBRID  SYSTEM-STRIKE  CONFIGURATION 


BUS  TRAPCIC  DFCCPPf'S  IT  ICN  PCR  GLOBAL  <=US  09 


TOTAL  TRAFFIC 
TRAFFIC  UTTLIZEC  DATA 

TBARFIC  utilized  FOR  HFADEF 
TRAFFIC  iJTILlZEr  FOR  SYNC 

trarpic  utilized  pcr  gar 


93.90  KBPS 
49.30  KROS 
39.20  KPOS 
0.0  KPPS 
4.90  KBPS 


53.04  PERCENT 
41.75  PERCENT 
0.0  PERCENT 
5.22  PERCENT 


» «x  «*  «4  4 <<444*  44  4444444  4 ««4*4  4*4  44  4<4***  4*  •«  44444444444  44V  4 «44«T;  44  K 


dp/m  system-strike  confiuration 


444444444444444  4 4 4444444V 4 44 44 444 4 4444444 4444444444444444 44444 444 

BUS  TRAFFIC  DECCHPOSITION  FOR  GLOBAL  PUS  99 


TOTAL  TRAFFIC 
TRAFFIC  UTILIZED  FOR  DATA 
traffic  UTILIZED  pCR  HEADER 
TRAFFIC  utilized  FOR  SYNC 

traffic  utilized  for  gap 


101.25  KBPS 
52.20  KBPS 
A3. 60  KBPS 
0.0  KBPS 
5.A5  KBPS 


51.56  PERCENT 
A3. 06  PERCENT 
0.0  PERCENT 
5.38  PERCENT 


444* 44 *44444 <444444444444v444444444444 44 4444444444444 444444444444 


Figure  D-2.  SNS  Result  Summary 
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Figure  0-3.  Interfunctional  Relationships 


TABLE  D-3.  SIGNAL  LIST  FOR  GUIDANCE  ALGORITHM 


Routine 


Ground  Track  Guidance 


Terrain  Following  Guidance 


Climb/Descend  and  Cruise 
Vertical  Guidance 


Weapon  Delivery 
Vertical  Guidance 


Weapon  Delivery 
Horizontal  Guidance 


Microwave  Landing 
System  Guidance 


Signal 

ACTUAL  PRESENT  POSITION  X 
ACTUAL  PRESENT  POSITION  Y 
PROGRAMMED  PRESENT  POSITION  X 
PROGRAMMED  PRESENT  POSITION  Y 
NEXT  CHECKPOINT  POSITION  X 
NEXT  CHECKPOINT  POSITION  Y 
PRESENT  HEADING 
CORRECT  HEADING 

RADAR  ALTITUDE 
PITCH  ATTITUDE 
VERTICAL  VELOCITY 
DESIRED  RADAR  ALTITUDE 
PITCH  ATTITUDE  CORRECTION 

ACTUAL  PRESENT  ALTITUDE 
PROGRAMMED  PRESENT  ALTITUDE 
BAROMETRIC  ALTITUDE 
TRUE  AIRSPEED 
PROGRAMMED  TRUE  AIRSPEED 
VERTICAL  VELOCITY 
PROGRAMMED  VERTICAL  VELOCITY 
PITCH  ATTITUDE  CORRECTION 


VERTICAL  POSITION 
VERTICAL  VELOCITY 
PITCH  ATTITUDE 
PITCH  RATE 

ESTIMATED  TIME  TO  RELEASE 
DESIRED  VERTICAL  VELOCITY 
DESIRED  VERTICAL  POSITION 
PITCH  ATTITUDE  CORRECTION 


PRESENT  HEADING 
ESTIMATED  TIME  TO  RELEASE 
DESIRED  HEADING 
HEADING  CORRECTION 

RANGE  TO  MLS  LOCATION 
bearing  TO  MLS  LOCATION 
ELEVATION  TO  MLS  LOCATION 
PROGRAMMED  RANGE  TO  MLS  LOCATION 
PROGRAMMED  BEARING  TO  MLS  LOCATION 
DESIRED  GROUND  TRACK 
PRESENT  HEADING 
PITCH  ATTITUDE  CORRECTION 
HEADING  CORRECTION 


In/Out 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

OUT 

IN 

IN 

IN 

IN 

OUT 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

OUT 


IN 

IN 

IN 

IN 

IN 

IN 

IN 

OUT 


IN 

IN 

IN 

OUT 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

OUT 

OUT 
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II.  SNS  SIMULATION  DATA  DEFINITION  PROCEDURE 


Tlie  following  major  steps  are  required  in  preparing  SNS  input  data: 

Definition  of  Mission  Scenario 

Mission  Scenario  Segmentation 

Mission  Segment  Functional  Definition 

Function  to  Task  Assignment 

Task  to  PE  Assignment 

Message  Flow  Analysis 

Data  Coding  (per  SNS  handbook). 

The  following  is  a description  of  the  procedure  used  to  obtain  the  data  for  the  SNS 
program: 

From  the  assumed  mission  scenearios,  obtain  the  mission  functions  required  to 
accomplish  the  mission  and  choose  the  segment  to  be  analyzed.  In  this  case, 
segment  8 of  the  strike  mission  (weapon  delivery  segment)  is  selected 

From  the  mission  segment  operational  time  table  (Table  4),  define  the  algorithms  and 
equipment  operating  and  from  the  task  assignment  table  (Tables  24,  25)  the 
number  of  processing  elements  to  be  used  in  the  simulation  (Table  D-4) 

The  messages  required  and  generated  by  each  task  have  to  be  defined  (from  Table  D-2) 
and  labeled  depending  on  whether  they  are  necessary  (over  100)  or  enhancing 
(over  300)  as  shown  in  Figure  D-3.  Messages  of  start/end  type  (task  initiation/ 
completion)  are  labeled  under  100,  and  the  number  of  them  must  be  equal  to  the 
number  of  executing  tasks  as  shown  in  Figure  D-4 

Once  the  above  are  established,  a predecessor/successor  relationship  flow  diagram  is 
needed  in  order  to  define  the  scheduling  time  for  first  initiation  of  each  task. 

Table  D-5  shows  the  required  SNS  data  for  all  tasks  as  obtained  by  the  above  mentioned 
procedure.  The  data  are  coded  the  same  way  as  referred  to  in  the  original  SNS  manual. 


TABLE  D-4.  SNS  TASK  ID/PE  ASSIGNMENT  (HYBRID  CONFIGURATION) 


Task 

Task  ID 

PE  Number 

Radar  Altimeter  Subsystem  Service  (RADALT) 

41 

3 

Inertial  Navigation  System  (INS) 

42 

2 

Radiation  Sensor  Subsystem  Service  (RADSNS) 

43 

6 

Air  Data  (AIRDTA) 

45 

3 

Status  Monitor  (STATMN) 

46 

3 

Narrowband  Data  Link  Subsystem  Service  (NBDL) 

47 

4 

Target  Position  Computation  (TGPSCM) 

48 

6 

impact  Point  Computation  (IMPTCM) 

49 

6 

Navigation  Filter  (NAVFIL) 

50 

2 

Flight  Control  (FLTCON) 

51 

5 

Steering  (STERNG) 

52 

3 

Guidance  (GUIDNC) 

53 

3 

Mission  Control  (MISCON) 

54 

3 

Wideband  Data  Link  Subsystem  Service  (WBDL) 

55 

9 

FLIR  Subsystem  Service  (FLIR) 

56 

8 

Weapon  Station  Subsystem  Service  (WPNSTN) 

57 

7 

Bus  Control  (BUSCON) 

•This  task  is  the  Global  Executive. 

* 

1 

TABLE  D-S.  SNS  DATA  TABLE 


Task  ID 

Start  Time 
O^s) 

Execution  Time 
(ps) 

Iteration  Time 
(ps) 

Memory 

(Words) 

41 

1,000 

157 

31,250 

180 

42 

2,000 

20,313 

31,250 

3,500 

43 

3,000 

625 

250,000 

700 

45 

4,000 

1,875 

250,000 

635 

46 

5,000 

938 

1 ,000,000 

1,050 

47 

6,000 

938 

62,500 

1,050 

48 

7,000 

1,563 

62,500 

380 

49 

21,350 

22,188 

62,500 

1,960 

SO 

22,350 

N/A 

2,000,000 

3,600 

51 

23,350 

14,063 

31,250 

3,350 

52 

26,150 

3,594 

62,500 

770 

53 

28,710 

2,188 

250,000 

2,500 

54 

42,600 

4,688 

62,500 

5,300 

55 

47,350 

157 

1 ,000,000 

220 

56 

48,400 

938 

62,500 

700 

57 

49,400 

938 

62,500 

650 
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APPENDIX  E 

DETAILED  RELIABILITY  DATA 


This  appendix  contains  the  detailed  reliability  tables  for  the  three  candidate  processing 
systems. 

As  stated  previously  in  this  report,  each  of  the  two  distributed  networks  considered  in  this 
study  is  a homogeneous  processing  system.  In  the  case  of  a nonhomogeneous  processing  system, 
using  a mix  of  microprocessor  types,  system  reliability  could  differ  from  that  shown  in  the 
following  tables.  In  general,  the  basic  failure  rate  for  an  individual  processing  element  varies  with 
the  complexity  of  that  element.  In  most  cases,  a PE  based  on  a 4-bit  or  8-bit  microprocessor  will 
have  a lower  failure  rate  than  a PE  based  on  a 16-bit  machine. 

In  the  following  tables,  where  two  different  PEs  contain  the  same  module  complement, 
the  failure  rates  are  the  same.  For  example,  the  Air  Data  and  Radar  Altimeter  PEs  contain  the 
same  modules  as  can  be  seen  from  Table  18. 

The  system  level  MTBFs  shown  in  Tables  E-1  through  E-21  are  given  for  each  system  and 
mission  configuration  in  three  different  categories: 

Total  serial  where  all  parts  of  the  system  are  considered 

Mission  success  where  only  mission-critical  entities  are  accounted  for 

Flight  success  where  only  flight-critical  parts  of  the  system  are  considered. 


TABLE  E-1.  RELIABILITY  PREDICTION  FOR  DP/M  SYSTEM- STRIKE 
CONFIGURATION  (TOTAL  SERIAL) 

Failure  Rate  Per  I O'*  Hours 


Name  of  Functional  Core  or 


Element 

Mission  Peculiar 

Ta  = 4S°C 

Ta  = 80°C 

Bus  Control 

Core 

70.13 

110.79 

INS 

Core 

103.31 

167.92 

Flight  Control 

Core 

80.36 

127.8 

GPS 

Core 

146.71 

242.06 

Mission  Control  and  Status 

Core 

97.07 

160.24 

Airdata 

Core 

58.66 

90.73 

Aircraft  Instrumentation 

Core 

58.66 

90.73 

Radar  Altimeter 

Core 

58.66 

90.73 

MLS 

Core 

58.66 

90.73 

Guidance  and  Steering 

Core 

74.12 

120.12 

NBDL 

Core 

58.66 

90.73 

IFF 

Core 

58.66 

90.73 

Power  Supplies 

Core 

88.22 

113.75 

Total  Failure  Rate  for  Core 

Functions 

1011.88 

1587.06 

TERCOM 

Mission  Peculiar 

103.31 

167.92 

Radiation  Sensor 

Mission  Peculiar  . 

Target  Position  Computation  Mission  Peculiar  / 

80.36 

127.8 

Impact  Point  Computation 

Mission  Peculiar  | 

Line  of  Sight 

Mission  Peculiar  ^ 

WBDL 

Mission  Peculiar 

58.66 

90.73 

FLIR 

Mission  Peculiar 

58.66 

90.73 

Weapons  Station 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  for  Mission  Peculiar  Functions 

359.65 

567.91 

Total  Failure  Rate  (Core  + 

Mission  Peculiar) 

1371.53 

2154.97 

Strike  Mission  MTBF 

= 1/Xt  = 

729  hours 

464  hours 
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TABLE  E-2.  RELIABILITY  PREDICTION  FOR  HYBRID  SYSTEM 
CONFIGURATION  (TOTAL  SEP'AL) 


Failure  Rate  Per 

Name  of  Functional 
Element 

Core  or 

Mission  Peculiar 

Ta  = 45°C 

Bus  Control 

Core 

70.13 

INS 

Core 

80.36 

Flight  Control 

Core 

80.36 

GPS 

Core 

146.71 

Mission  Control 

Core  \ 

Air  data 

Core  1 

Aircraft  Instrumentation 

Core  I 

Radar  Altimeter 

Core  \ 

125.01 

MLS 

Core  1 

Guidance  and  Steering 

Core  1 

Status  Monitoring 

Core  / 

NBDL 

Core  ) 

NAV  Filter 

Core  1 

114.86 

IFF 

Core  1 

Power  Supplies 

Core 

62.84 

Total  Failure  Rate  for  Core 

Functions 

680.27 

TERCOM 

Mission  Peculiar 

103.31 

Radiation  Sensor 

Mission  Peculiar 

Target  Position  Computation 

Mission  Peculiar 

80.36 

Impact  Point  Computation 

Mission  Peculiar 

Line  of  Sight 

Mission  Peculiar 

WBDL 

Mission  Peculiar 

58.66 

FLIR 

Mission  Peculiar 

58.66 

Weapon  Station 

Mission  Peculiar 

58,66 

Total  Failure  Rate  for  Mission  Peculiar  Functions  359.65 

Total  Failure  Rate  (Core  + Mission  Peculiar)  1039.92 


Strike  Mission  MTBF  = 1/X^  962  hours 


-STRIKE 

10‘  Hours 

Tx  = 80°C 

110.79 

127.8 

127.8 

242.06 


204.99 


188.13 

79.37 

1080.94 

167.92 

127.8 


90.73 
90.73 
90.73 
567.91 
1648.85 
607  hours 


TABLE  E-3.  RELIABILITY  PREDICTION  FOR  CENTRALIZED  SYSTEM-STRIKE 
CONFIGURATION  (TOTAL  SERIAL) 

Failure  Rate  per  I0‘  Hours 


Name  of  Functional 
Element 

Main  Computer  or 
Remote  Terminal 

Ta  = 4S°C 

Ta  = 80°C 

MCCR 

Main  Computer 

34.80 

48.03 

ADDRESS 

Main  Computer 

42.62 

50.76 

DATA 

Main  Computer 

147.20 

202.68 

CORE  STACK 

Main  Computer 

59.28 

73.68 

APU 

Main  Computer 

24.08 

29.89 

MCU 

Main  Computer 

43.30 

57.80 

FPAPU 

Main  Computer 

35.27 

45.46 

SERIAL  INPUT 

Main  Computer 

13.61 

16.61 

PARALLEL  INPUT 

Main  Computer 

10.86 

13.24 

SERIAL  OUTPUT 

Main  Computer 

14.32 

17.82 

Interrupt  Assy 

Main  Computer 

16.53 

20.20 

P Bus  Decode 

Main  Computer 

11.64 

15.58 

Power  Supply  Assy 

Main  Computer 

34.00 

46.59 

Total  Failure  Rate  for  Main  Computer 

487.51 

638.34 

Remote  Terminals  for 
Following  Functions: 

Bulk  Storage 

Remote  Terminal 

46.49 

68.56 

IMU  and  Remote  Compass 

Remote  Terminal 

46.49 

68.56 

Flight  Control 

Remote  Terminal 

46.49 

68.56 

GPS 

Remote  Terminal 

46.49 

68.56 

Air  data 

Remote  Terminal  ^ 

Aircraft  Instrumentation 

Remote  Terminal  1 

46.49 

68.56 

Radar  Altimeter 

Remote  Terminal  ( 

MLS 

Remote  Terminal  1 

NBDL  and  IFF  Transponder 

Remote  Terminal 

46.49 

68.56 

TERCOM 

Remote  Terminal 

46.49 

68.56 

Radiation  Sensor 

Remote  Terminal 

46.49 

68.56 

WBDL 

Remote  Terminal 

46.49 

68.56 

FLIR 

Remote  Terminal 

46.49 

68.56 

Weapon  Station 

Remote  Terminal 

46.49 

68.56 

Total  Failure  Rate  for  Remote  Terminals 

511.39 

754.16 

Total  Failure  Rate  for  Main  Computer  + Terminals 

998.9 

1392.50 

Strike  Mission  MTBF  = 

1/Xj 

1001  hours 

718  hours 
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TABLE  E4.  RELIABILITY  PREDICTION  FOR  DP/M  SYSTEM- STRIKE 
CONFIGURATION  (MISSION  SUCCESS) 


Failure  Rate  per  I0‘  Hours 


Name  of  Functional  Core  or 


Element 

Mission  Peculiar 

Ta  = «°C 

Ta  = 80°C 

Bus  Control 

Core 

70.13 

110.79 

INS 

Core 

103.31 

167.92 

Flight  Control 

Core 

80.36 

127.80 

GPS 

Core 

146.71 

242.06 

Mission  Control  and  Status 

Core 

97.07 

160.24 

Air  Data 

Core 

58.66 

90.73 

Radar  Altimeter 

Core 

58.66 

90.73 

Guidance  and  Steering 

Core 

74.12 

120.12 

IFF 

Core 

58.66 

90.73 

Power  Supplies 

Core 

88.22 

113.75 

Total  Failure  Rate  for  Core  Functions 
Affecting  Mission  Success 

835.9 

1314.87 

TERCOM 

Mission  Peculiar 

103.31 

167.92 

Radiation  Sensor 

Mission  Peculiar 

Target  Position  Computation 

Mission  Peculiar 

80.36 

127.8 

Impact  Point  Computation 

Mission  Peculiar 

Line  of  Sight 

Mission  Peculiar 

Weapons  Station 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  for  Mission 
Peculiar  Functions  Affecting 
Mission  Success 

242.33 

386.45 

Total  Failure  Rate  for  Core 
+ Mission  Peculiar  Functions 
Affecting  Mission  Success 

1078.23 

r7dT32 

Strike  Mission  Success  MTBF  = l/Xj 

928  hours 

588  hours 
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TABLE  E-S.  RELIABILITY  PREDICTION  FOR  HYBRID  SYSTEM -STRIKE 
CONFIGURATION  (MISSION  SUCCESS) 


Failure  Rate  Per 

10''  Hours 

Name  uf  Functional 

Core  or 

T^  = 4S°C 

Ta  = 80°C 

Element 

Mission  Peculiar 

Bus  Control 

Core 

70.13 

1 10.79 

INS 

Core 

80.36 

127.8 

Flight  Control 

Core 

80.36 

127.8 

GPS 

Core 

146.71 

242.06 

Mission  Control 

Core  \ 

Air  Data 

Core  1 

Radar  Altimeter 

Core  1 

Aircraft  Instrumentation 

Core  \ 

12.S.01 

204.99 

MLS 

Core  1 

Guidance  and  Steering 

Core  1 

Status  Monitoring 

Core  / 

Navigation  Filter 

Core  \ 

IFF 

Core  > 

114.86 

188.13 

NBDL 

Core  ; 

Power  Supplies 

Core 

62.84 

79.37 

Total  Failure  Rate  for  Core 
Functions  Affecting  Mission 
Success 

680.27 

1080.94 

TFRCOM 

Mission  Peculiar 

103.31 

167.92 

Radiation  Sensor 

Mission  Peculiar  i 

Target  Position  Computation 

Mission  Peculiar  1 

80.36 

127.8 

Impact  Point  Compulation 

Mission  Peculiar  i 

Line  of  Siglit 

Mission  Peculiar  1 

Weapon  Station 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  for  Mission 
Peculiar  Functions  Affecting 
Mission  Success 

242.3J 

386.45 

Total  Failure  Rate  for  Core 
+ Mission  Peculiar  Functions 
Affecting  Mission  Success 

922.6 

1467.39 

Strike  Mission  Success  MTBF  = 1/X-j^ 

1084  hours 

682  hours 

TABLE  E-«.  RELIABILITY  PREDICTION  FOR  CENTRALIZED  SYSTEM-STRIKE 
CONFIGURATION  (MISSION  SUCCESS) 

Failure  Rate  Per  I O'*  Hours 


Name  of  Functional 
Element 

Main  Computer  or 
Remote  Terminal 

Ta  = 45°C 

Ta  = 80°C 

Main  Computer 

Main  Computer 

487.51 

638.34 

(Refer  to  Table  E-3  for 
detailed  breakout) 

Remote  Terminals  for 
Following  Functions: 

Bulk  Storage 

Remote  Terminal 

46.49 

68.56 

IMU  & Remote  Compass 

Remote  Terminal 

46.49 

68.56 

Fliglit  Control 

Remote  Terminal 

46.49 

68.56 

GPS 

Remote  Terminal 

46.49 

68.56 

Air  Data 

Remote  Terminal  ^ 

1 

Aircraft  Instrumentation 

Remote  Terminal  1 

> 46.49 

68.56 

Radar  Altimeter 

Remote  Terminal  | 

MLS 

Remote  Terminal  ^ 

1 

NBDL 

IFF  Transponder 

Remote  Terminal  | 
Remote  Terminal  f 

► 46.49 

68.56 

TERCOM 

Remote  Terminal 

46.49 

68.56 

Radiation  Sensor 

Remote  Terminal 

46.49 

68.56 

Weapon  Station 

Remote  Terminal 

46.49 

68.56 

Total  Failure  Rate  for 
Terminals  Affecting  Mission 
Success 

418.41 

617.04 

Total  Failure  Rate  for  Main 
Computer  + Terminals  Affecting 
Mission  Success 

905.92 

1255.38 

Strike  Mission  Success  MTBF  = 1/Xf 

1 1 04  hours 

797  hours 

I 


TABLE  E-7.  RELIABILITY  PREDICTION  FOR  DP/M  SYSTEM-RECCE 
CONFIGURATION  (TOTAL  SERIAL) 

Failure  Rate  Per  1 O'’  Hours 


Name  of  Functional 
Element 

Core  or 

Mission  Peculiar 

Ta  = 45°c 

Ta  = 80°c 

Core 

Core  Electronics 

1011.88 

1587.06 

(Refer  to  Table  E-1  for 
detailed  breakout) 

Pliotocamera 

Mission  Peculiar 

58.66 

90.73 

IR  Line  Scanner 

Mission  Peculiar 

58.66 

90.73 

TERCOM 

Mission  Peculiar 

103.31 

167.92 

WBDL 

Mission  Peculiar 

_58.6_6 

90.73 

Total  Failure  Rate  of 
Mission  Peculiar  Functions 

279.29 

440.11 

Total  Failure  Rate  of 
Core  + Mission  Peculiar 
Functions 

1291.17 

2027.17 

Recce  Mission  MTBF  = 

i/Xt 

775  hours 

493  hours 

TABLE  E-8.  RELUBILITY  PREDICTION  FOR  HYBRID  SYSTEM-RECCE 
CONFIGURATION  (TOTAL  SERIAL) 


Name  of  Functional 
Element 

Core  or 

Mission  Peculiar 

Failure  Rate  Per  10‘  Hours 
Ta  = 45°C  Ta  = 80°C 

Core 

Core 

680.27 

1080.94 

(Refer  to  Table  E-2  for 
Detailed  breakout) 

Photocamera 
IR  Line  Scanner 

Mission  Peculiar 

58.66 

90.73 

TERCOM 

Mission  Peculiar 

103.31 

167.92 

WBDL 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  of 
Mission  Peculiar  Functions 

220.63 

349.38 

Total  Failure  Rate  of 
Core  + Mission  Peculiar 
Functions 

900.9 

1430.32 

Recce  Mission  MTBF  = 

l/X-j- 

1110  hours 

699  hours 

TABLE  E-9.  RELIABILITY  PREDICTION  FOR  CENTRALIZED  SYSTEM-RECCE 
CONFIGURATION  (TOTAL  SERIAL) 


Failure  Rate  Per  10‘  Hours 


Name  of  Functional 

Core  or 

Ta  = 4S°C 

Ta  = 80°C 

Element 

Mission  Peculiar 

Main  Computer 

(Refer  to  Table  E-3  for 
detailed  breakout) 

Main  Computer 

487.51 

638.34 

Remote  Terminals  for  the 
Following  Functions: 

Bulk  Storage 

Remote  TerminaL 

46.49 

68.56 

IMU  and  Remote  Compass 

Remote  Terminal 

46.49 

68.56 

Flight  Control 

Remote  Terminal 

46.49 

68.56 

GPS 

Remote  Terminal 

46.49 

68.56 

Air  Data 

Remote  Terminal  ] 

Aircraft  Instrumentation 

Remote  Terminal  1 

68.56 

Radar  Altimeter 

Remote  Terminal  | 

1 46.49 

MLS 

Remote  Terminal  J 

NBDL 

Remote  Terminal  ] 

1 46.49 

68.56 

IFF  Transponder 

Remote  Terminal  j 

f 

Photo  Camera 

Remote  Terminal  | 

, 46.49 

68.56 

or  IR  Line  Scanner 

Remote  Terminal  J 

r 

1 

TERCOM 

Remote  Terminal 

46.49 

68.56 

WBDL 

Remote  Terminal 

46.49 

68.56 

Total  Failure  Rate  for 
Remote  Terminals 

418.41 

617.o4 

Total  Failure  Rate  for  Main 
Computer  + Remote 
Terminals 

905.92 

1255.38 

Recce  Mission  MTBF  = 

1/X-p 

1 104  hours 

797  hours 

TABLE  E-10.  RELIABILITY  PREDICTION  FOR  DP/M  SYSTEM-REECE 
CONFIGURATION  (MISSION  SUCCESS) 


Failure  Rate  Per  10*’  Hours 


Name  of  Functional 

Core  or 

Ta  = 80°c 

Element 

Mission  Peculiar 

Ta  = 4S“C 

Bus  Control 

Core 

70.13 

110.79 

INS 

Core 

103.31 

167.92 

Flight  Control 

Core 

80.36 

127.8 

GPS 

Core 

146.71 

242.06 

Mission  Control  and  Status 

Core 

97.07 

160.24 

Air  Data 

Core 

58.66 

90.73 

Radar  Altimeter 

Core 

58.66 

90.73 

Guidance  and  Steering 

Core 

74.12 

120.12 

IFF 

Core 

58.66 

90.73 

Power  Supplies 

Core 

79.76 

102.29 

Total  Failure  Rate  of 
Core  Functions  Affecting 
Recce  Mission  Success 

827.43 

1303.41 

IR  Scanner)  ) 

Mission  Peculiar 

58.66 

Xeff  = 

90.73  Xeff  = 

WBDL  f > operating 

Mission  Peculiar 

58.66 

50.28 

90.73  77.7 

Photo  i redundancy 

Mission  Peculiar 

58.66 

90.73 

camera 

TERCOM 

Mission  Peculiar 

103.31 

167.92 

Total  Failure  Rate  of 
Mission  Peculiar  Functions 
Affecting  Mission  Success 

1«.5~9 

245.62 

Total  Failure  Rate  of 
Core  + Mission  Peculiar 
Functions  Affecting 
Mission  Success 

981.02 

1549.03 

Recce  Mission  Success  MTBF 

1019  hours 

646  hours 

TABLE  E-II.  RELIABILITY  PREDICTION  FOR  HYBRID  SYSTEM-RECCE 
CONFIGURATION  (MISSION  SUCCESS) 


Failure  Rate  Per  10^  Hours 

Name  of  Functional 

Core  or 

Ta  = 4S“C 

Ta  = 80°c 

Element 

Mission  Peculiar 

Bus  Control 

Core 

70.13 

1 10.79 

INS 

Core 

80.36 

127.8 

Fliglit  Control 

Core 

80.36 

127.8 

GPS 

Core 

146.71 

242.06 

Mission  Control 

Core  \ 

Air  Data 

Core  / 

Radar  Altimeter 

Core  \ 

125.01 

204.99 

Guidance  and  Steering 

Core  ( 

Status  Monitoring 

Core  1 

NAV  Filter 

Core 

114.86 

188.13 

Power  Supplies 

Core 

62.84 

79.37 

Total  Failure  Rate  of 
Core  Functions  Affecting 
Mission  Success 

680.27 

1080.94 

IR  Scanner 

Mission  Peculiar  f 

506 

90.73 

Photo  Camera 

Mission  Peculiar  f 

WBDL 

Mission  Peculiar 

58.66 

90.73 

TERCOM 

Mission  Peculiar 

103.31 

162:92 

Total  Failure  Rate  of 
Mission  Peculiar  Functions 

220.63 

349.38 

Total  Failure  Rate  of  Core 
+ Mission  Peculiar  Functions 

900.9 

1430.32 

Affecting  Recce  Mission  Success 

Recce  Mission  MTBF  = 

1/Xt 

1110  hours 

699  hours 
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TABLE  E 12.  RELUBiLITY  PREDICTION  FOR  CENTRALIZED  SYSTEM-RECCE 
CONFIGURATION  (MISSION  SUCCESS) 

Failure  Rate  Per  10*  Hours 


Name  of  Functional 
Element 

Main  Computer  or 
Remote  Terminal 

Ta  = 45°C 

Ta  = 80°c 

Main  Computer 
(Refer  to  Table  E-3  for 
detailed  breakout) 

Main  Computer 

487.51 

638.34 

Remote  Terminals  for  the 
Following  Functions: 

Bulk  Storage 

Remote  Terminal 

46.49 

68.56 

IMU  and  Remote  Compass 

Remote  Terminal 

46.49 

68.56 

Flight  Control 

Remote  Terminal 

46.49 

68.56 

GPS 

Remote  Terminal 

46.49 

68.56 

Air  Data 

Aircraft  Instrumentation 
Radar  Altimeter 
MLS 

Remote  Terminal 
Remote  Terminal  1 
Remote  Terminal  | 
Remote  Terminal  , 

1 46.49 

( 

68.56 

NBDL 

IFF  Transponder 

Remote  Terminal  1 
Remote  Terminal  J 

^ 46.49 

68.56 

Photo  Camera 
or  IR  Line  Scanner 

Remote  Terminal  ^ 
Remote  Terminal  ) 

, 46.49 

68.56 

TERCOM 

Remote  Terminal 

46.49 

68.56 

Total  Failure  Rate  for 
Remote  Terminals  Affecting 
Mission  Success 

371,92 

548.48 

Total  Failure  Rate  for  Main 
Computer  + Remote  Terminals 
Affecting  Recce  Mission 
Success 

859.43 

1186.82 

Recce  Mission  Success  MTBF  = l/Xj 

1 164  hours 

843  hours 
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TABLE  E-13.  REUABIUTY  PREDICTION  FOR  DP/M  SYSTEM-EW 
CONFIGURATION  (TOTAL  SERUL) 


Failure  Rate  Per  10‘  Hours 


Name  of  Functional 

Core  or 

Ta  = 45°c 

Ta  = 80°c 

Element 

Mission  Peculiar 

Core 

Core 

1011.88 

1587.06 

(Refer  to  Table  E-1  for 
detailed  breakout) 

Active  Jam  Control 

Mission  Peculiar 

58.66 

90.73 

Threat  Warning 
Receiver 

Mission  Peculiar 

58.66 

90.73 

Chaff  Dispenser 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  of 
Mission  Peculiar  Functions 

175.98 

272.19 

Total  Failure  Rate  of 
Core  + Mission 
Peculiar  Functions 

1187.86 

1859.25 

EW  Mission  MTBF  = 

1/Xt 

842  hours 

538  hours 

TABLE  E-14.  RELUBILITY  PREDICTION  FOR  HYBRID  SYSTEM-EW 
CONFIGURATION  (TOTAL  SERIAL) 

Failure  Rate  Per  10*  Hours 


Name  of  Functional 

Core  or 

Ta  = 45“C 

Ta  = 80°C 

Element 

Mission  Peculiar 

Core 

Core 

680.27 

1080.94 

(Refer  to  Table  E-2  for 
detailed  breakout) 

Active  Jam  Control 
Threat  Warning  Receiver 

Mission  Peculiar 

80.36 

127.8 

Chaff  Dispenser 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  for 
Mission  Peculiar  Functions 

139.02 

218.53 

Total  Failure  Rate  of 
Core  + Mission  Peculiar 
Functions 

819.29 

1299.47 

EW  Mission  MTBF  = l/Xj 

1221  hours 

770  hours 
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TABLE  E-IS.  REUABILITY  PREDICTION  FOR  CENTRALIZED  SYSTEM-EW 
CONFIGURATION  (TOTAL  SERIAL) 

Failure  Rate  Per  10'’  Hours 


Name  of  Functional 

Main  Computer  or 

Ta  = 45°C 

Ta  = 80°c 

Element 

Remote  Terminal 

Mam  Computer 

(Refer  to  Table  B3  for 
detailed  breakout) 

Main  Computer 

487.51 

638.34 

Remote  Terminals  for 
Following  Functions: 

Bulk  Storage 

Remote  Terminal 

46.49 

68.56 

IMU  and  Remote 
Compass 

Remote  Terminal 

46.49 

68.56 

Fliglit  Control 

Remote  Terminal 

46.49 

68.56 

GPS 

Remote  Terminal 

46.49 

68.56 

Air  Data 

Remote  Terminal  j 

Aircraft  Instrumentation 

Remote  Terminal  ( 

46.49 

68.56 

Radar  Altimeter 

Remote  Terminal  1 

MLS 

Remote  Terminal  / 

NBDL 

Remote  Terminal  i 

46.49 

68.56 

IFF  Transponder 

Remote  Terminal  / 

Active  Jammer 

Remote  Terminal 

46.49 

68.56 

Threat  Warning  Receiver 

Remote  Terminal 

46.49 

68.56 

Chaff  Dispenser 

Remote  Terminal 

46.49 

68.56 

Total  Failure  Rate 
for  Terminals 

418.41 

617.04 

Total  Failure  Rate  for 
Main  Computer  + Remote 
Terminals 

905.92 

1255.38 

EW  Mission  MTBF  = 

1 /Xj 

1 104  hours 

797  hours 

TABLE  E-16.  RELUBILITY  PREDICTION  FOR  DP/M  SYSTEM-EW 
CONFIGURATION  (MISSION  SUCCESS) 


Name  of  Functional 

Core  or 

Failure  Rale 

Per  I0‘  Hour 

Element 

Mission  Peculiar 

Ta  = 4S°C 

Ta  = 80°  1 

Bus  Control 

Core 

70.13 

110.79 

INS 

Core 

103.31 

167.92 

Flight  Control 

Core 

80.36 

127.8 

GPS 

Core 

146.71 

242.06 

Mission  Control  and  Status 

Core 

97.07 

160.24 

Air  Data 

Core 

58.66 

90.73 

Radar  Altimeter 

Core 

58.66 

90.73 

Guidance  and  Steering 

Core 

74.12 

120.12 

IFF 

Core 

58.66 

90.73 

Power  Supplies 

Core 

79.76 

102.29 

Total  Failure  Rate  of 
Core  Functions  Affecting 

827.43 

1303.41 

Mission  Success 

Chaff  Dispenser 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  of 

886.09 

1394.14 

Core  + Mission  Peculiar 
Functions  Affecting 
EW  Mission  Success 

EW  Mission  Success  MTBF  = l/Xj  1129  hours  717  hours 


i 
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TABLE  E-17.  RELIABILITY  PREDICTION  FOR  HYBRID  SYSTEM-EW  ] 

CONFIGURATION  (MISSION  SUCCESS)  I 


Failure  Rale 

Per  I0‘  Hours 

Name  of  Functional 

Core  or 

Ta  = 4S“C 

Ta  = 80°C 

Element 

Mission  Peculiar 

Bus  Control 

Core 

70.13 

110  79 

INS 

Core 

80.36 

127.8 

Flight  Control 

Core 

80.36 

127.8 

GPS 

Core 

146.71 

242.06 

Mission  Control 

Core  \ 

Air  Data 

Core  1 

Radar  Altimeter 

Core  S 

125.01 

204.99 

Guidance  and  Steering 

Core  1 

Status  Monitoring 

Core  ^ 

NAV  Filter 

Core 

114.86 

188.13 

Power  Supplies 

Core 

62.84 

79.37 

Total  Failure  Rate  for 
Core  Functions  Affecting 
Mission  Success 

680.27 

1080.94 

Chaff  Dispenser 

Mission  Peculiar 

58.66 

90.73 

Total  Failure  Rate  for 
Core  and  Mission  Peculiar 

738.93 

1171.67 

Functions  Affecting  E.W. 
Mission  Success 

EW  Mission  Success  MTBF  = 1/X-j-  1353  hours  854  hours 
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TABU  E-18.  RELIABILITY  PREDICTION  FOR 

CENTRALIZED  SYSTEM-EW 

CONFIGURATION  (MISSION 

SUCCESS 

Failure  Rate 

Per  10‘  Hours 

Name  of  Functional 

Main  Computer  or 

Ta  = 4S“C 

Ta  = 80°C 

Element 

Remote  Terminal 

Main  Computer 

(Refer  to  Table  E-3  for 
detailed  breakout) 

Main  Computer 

487.51 

638.34 

Remote  Terminals  for  the 
Following  Functions: 

68.56 

Bulk  Storage 

Remote  Terminal 

46.49 

(MU  and  Remote  Compass 

Remote  Terminal 

46.49 

68.56 

Fllglit  Control 

Remote  Terminal 

46.49 

68.56 

GPS 

Remote  Terminal 

46.49 

68.56 

Air  Data 

Remote  Terminal  J 

Aircraft  Instrumentation 

Remote  Terminal  | 

Radar  Altimeter 

Remote  Terminal  ( 

46.49 

68.56 

MLS 

Remote  Terminal  1 

NBDL 

Remote  Terminal  i 

46.49 

68.56 

IFF  Transponder 

Remote  Terminal  / 

Chaff  Dispenser 

Remote  Terminal 

46.49 

68.56 

Total  Failure  Rate  for 
Remote  Terminals  Affecting 
Mission  Success 

325.43 

479.92 

Total  Failure  Rate  for  Main 
Computer  + Remote  Terminal 
Affecting  EW  Mission  Success 

812.94 

1 1 18.26 

EW  Mission  Success  MTBF 

= IAt 

1230  hours 

894  hours 

TABLE  E-19.  RELIABILITY  PREDICTION 

FOR  SAFE  FLIGHT 

OF 

AIRCRAFT -DP/M  SYSTEM 

Failure  Rate 

Per  10®  Hours 

Name  of  Functional 

Core  or 

Ta  = 4S“C 

Ta  = 80°C 

Element 

Mission  Peculiar 

Bus  Control 

Core 

70.13 

110.79 

INS 

Core 

103.31 

167.92 

Flight  Control 

Core 

80.36 

127.8 

Mission  Control  and  Status 

Core 

97.07 

160.24 

Air  Data 

Core 

58.66 

90.73 

Guidance  and  Steering 

Core 

74.12 

120.12 

IFF 

Core 

58.66 

90.73 

Power  Supplies 

Core 

88.22 

113.75 

Total  Failure  Rate 

630.53 

982.08 

Safety  of  Flight  MTBF 

II 

H 

1586  hours 

1018  hours 
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TABLE  E-20.  RELIABILITY  PREDICTION  FOR  SAFE  FLIGHT 
OF  AIRCRAFT -HYBRID  SYSTEM 


Failure  Rale 

Per  10*  Hours 

Name  of  Functional 

Core  or 

Element 

Mission  Peculiar 

Ta  = 45“C 

Ta  = 80°C 

Bus  Control 

Cote 

70.13 

110.79 

INS 

Core 

80.36 

127.8 

Flight  Control 

Core 

80.36 

127.8 

Mission  Control 

Core  j 

1 

Ait  Data 

Cote  1 

[ 

Ciuidance  and  Steering 

Core  j 

125.01 

204.99 

Status  Monitoring 

Core  ^ 

1 

NBDL 

Core  j 

1 

NAV'  Filter 

Core ' 

114.86 

188.13 

IFF 

Core  J 

1 

Power  Supplies 

Core 

^.84 

79.37 

Total  Failure  Rate 

533.56 

838.88 

Safety  of  Flight  MTBF  = 

1/X-j- 

1874  hours 

1 192  hours 

TABLE  E-21.  RELIABILITY  PREDICTION  FOR  SAFE  FLIGHT 
OF  AIRCRAFT-CENTRALIZED  SYSTEM 


Failure  Rate  Per  10*  Hours 


Name  of  Functional 

Main  Computer  or 

Ta  = 45*C 

Ta  = 80°c 

Element 

Remote  Terminal 

Main  Computer 
(Refer  to  Table  E-3  for 
detailed  breakout) 

Main  Computer 

487.51 

638.34 

Remote  Terminals  for  the 
Following  Functions: 

IMU  and  Remote  Compass 

Remote  Terminal 

46.49 

68.56 

Flight  Control 

Remote  Terminal 

46.49 

68.56 

Radar  Altimeter 

Remote  Terminal 

Air  Data 

Remote  Terminal 

46.49 

68,56 

Aircraft  Instrumentation 
MLS 

NBDL  and 

IFF  Transponder 

Total  Failure  Rate  for  Remote 

Remote  Terminal 
Remote  Terminal 
Remote  Terminal 
Remote  Terminal 

46.49 

68.56 

185.96 

274.24 

Terminals  Affecting  Safety  of 

Flight 

Total  Failure  Rate  of  Main 

673.47 

9T2.5R 

Computer  + Remote  Terminals 
Affecting  Safety  of  Flight 

Safety  of  Flight  MTBF  = 

IAt 

1485  hours 

1096  hours 

1 


1 
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APPENDIX  F 

PROCESSING  SYSTEM  LCC  MODEL 
I.  GENERAL 

The  lile-cycle  cost  (LCC)  model  which  was  employed  in  the  ARPV  study  is  summarized 
by  the  block  diagram  in  Figure  F-l.  The  total  cumulative  life  cycle  cost  at  the  end  of  “T”  years 
is  the  sum  of  the  acquisition  cost  (CACQj  and  sustaining  cost  (CSUS)  as  shown  in  this  figure. 
The  following  sections  contain  a block-by-block  discussion  of  each  cost  category  appearing  in 
Figure  F- 1 . 


II.  ACQUISITION  COST 

A.  DESIGN  AND  DEVELOPMENT  COST 

Ihe  design  and  development  cost  is  given  by  the  following  equation. 

CDAD  = CDADP  -i-  CDADPS  + CDADS  -^  CDADSS  (F-l ) 

where 

CDAD  = design  and  development  (D&D)  cost 
CDADP  = prime  equipment  D&D  cost  (hardware) 

CDADPS  = prime  equipment  D&D  cost  (software) 

CDADS  = support  equipment  D&D  cost  (hardware) 

CDADSS  = support  equipment  D&D  cost  (software). 

B.  NONRECURRING  INVESTMENT  COSTS 

I'hc  nonrecurring  investment  costs  consist  of  Ihe  initial  provisioning  cost,  initial  training 
cost,  and  initial  technical  data  cost. 

I.  Initial  Provisioning  Cost 

CIP  = XLII  • CPLII  (F-2) 


where 

CIP  = initial  provisioning  cost 

XL.ll  = number  of  line  items  introduced  into  the  supply  system 
CPLIl  = cost  per  line  item  introduction. 

2.  Initial  Training  Cost 


CIT  = XM1 1 • CITC 


( F-3 ) 


17.^ 


Figure  F-l.  ARPV  Processor  LCC  Model 


wfierc 


3. 


where 


C'lT  = initial  training  cost 
XM  11  = luiinber  of  instiiictors  initially  trained 
( i rr  = initial  training  course  cost  per  student. 

Initial  Technical  Data  Cost 

cn  u = XTDPr  • (cppc  <■  crpd) 

( 111)  = initial  technical  data  cost 
X I DPC  = number  of  unique  technical  data  pages  created 
CPPC  = cost  of  creating  a page  of  technical  data 
CRPD  = cost  of  technical  data  reproduction  per  page. 


4.  Nonrecurring  Investment  Cost 


CINR  = CIP  + cn  + CITD 


where 


(F-4) 


(F-5) 


CINR  = nonrecurring  investment  cost 
CIP  = initial  provisioning  cost 
CIT  = initial  training  cost 
CFl'l)  = initial  technical  data  <.ost. 

C.  RECURRING  INVESTMENT  COSTS 

rile  recurring  investment  costs  include  the  costs  of  the  prime  and  support  equipments  and 
initial  spares,  installation  cost,  and  cost  of  first  destination  transportation. 


1. 


Installation  Costs 


CTNS  = XIII  I • XR(I)  + CMIH 


(F-6) 


where 


CINS  = installation  cost  per  equipment 
XHLI  = manhours  of  installation  labor  per  equipment 
XR(I)  = labor  rate  per  manhour  lor  installation  personnel 
C.MIH  = material  cost  of  aircraft  interface  hardware. 
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2.  First-Destination  Transportation  Cost 


CFDT  = WPEISC  • ANMFD  • CPPPMT  + CPPE  • WPEISC 

where 

CFDT  = first-destination  transportation  cost 
WPEISC  = weight  of  equipment  and  initial  spares  plus  container 
ANMFD  = average  one-way  distance,  from  origin  to  destination 
CPPPMT  = cost  for  transportation  of  equipment  per  pound  per  mile 
CPPE  = cost  of  packing  equipment-including  labor  and  materials. 

3.  Prime  Equipment  and  Initial  Spares 

ClSPj  = XPj  (CUNITPj  + CUNlTSj  + CPElSj  + CINS  + CFDT) 

where 

ClSPj  = cost  of  prime  equipment  and  initial  spares  in  \th  year 
XPj  = number  of  prime  equipment  acquired  in  \th  year 
CUNITPj  = prime  equipment  (software)  unit  cost  in  Uh  year 
CPEISj  = prime  equipment  initial  spares  cost  in  ith  year 
CINS  = installation  cost  per  equipment 
CFDT  = first-destination  transportation  cost  per  equipment. 

i 

. j 4.  Support  Equipment  and  Initial  Spare 

I a.  Flight  Line  AGE 

CFLj  = XOSj  (CNlTOj  + CISTOj) 

■ where 

CFLj  = cost  of  flight-line  or  organizational  level  AGE 

\ 

'■  XOSj  = number  of  sets  of  flight-line  AGE  acquired 

I during  i//i  year 

1 CNlTOj  = average  unit  cost  of  flight-line  AGE  acquired  in 

I \th  year 

. , CISTOj  = flight-line  AGE  initial  spares  cost-percent  of  unit 

' cost-in  ith  year. 

( 

b.  Intermediate- Level  A GE 


CITj  = XlSj  (CNlTIj  + ClSTIj) 


where 


ClTj  = cost  of  inlennediatc-levcl  AGH 

XIS,  = number  of  sets  of  intermediate-level  AGE  acquired 
during  ith  year 

CNlTlj  = average  unit  cost  of  intermediate-level  AGE  acquired 
in  iih  year 

CISTlj  = intermediate-level  AGE  initial  spares  cost-*percent 
of  unit  cost-m  ith  year. 

c.  Depot- Level  AGE 


CDl,  = XDSj  (CNlTDi  -t-  CISTDj) 


(F-11) 


where 

CIDj  = cost  of  depot-le\el  AGE 

XDSj  = number  of  sets  of  depot-level  AGE  acquired 
during  ith  year 

CNITDj  = average  unit  cost  of  depot-level  AGE  acquired 
in  ith  year 

CISTDj  = depot-level  AGE  initial  spares  cost-percent  of 
unit  cost-in  ith  year. 

d.  Support  Equipment  and  Initial  Spares 

CSSPj  = CEL,  -I-  ClLj  + CIDj  (F-1  2) 

where 

CSSPj  = cost  of  support  equipment  and  initial  spares 
CFLj  = cost  of  flight-line  AGE 
ClLj  = cost  of  intermediate-level  AGE 
CIDj  = cost  of  depot-level  AGE. 

5.  Recurring  Investment  Costs 


CIR  = CISP,  -r  CSSP, 


(F-13) 


where 

CIR  = recurring  investment  costs 
CISPj=  prime  equipment  and  initial  spares  cost 
CSSPj  = support  equipment  and  initial  spares  cost 


D.  ACQUISITION  COST 


The  acquisition  cost  is  the  arithmetic  sum  of  D&D  and  nonrecurring  and  recurring 
investment  costs. 


CACQi  = CDAU  + CINR  + CIR 


( F- 1 4 ) 


where 

CACQi  = acquisition  cost  during  \th  year 
CDAD  = design  and  development  cost 
CINR  = nonrecurring  investment  cost 
CIR  = recurring  investment  cost. 

III.  SUSTAINING  COSTS 

The  sustaining  costs  are  the  sums  of  scheduled  and  unscheduled  maintenance,  condemna- 
tion, checkout,  energy  consumption,  supply  management,  annual  maintenance  facility  space, 
annual  training,  annual  recurring  technical  data  management,  annual  recurring  support  equipment 
maintenance,  and  annual  software  costs. 

A.  SCHEDULED  AND  UNSCHEDULED  MAINTENANCE  COSTS 
1.  Unscheduled  (Random)  Maintenance  Costs 
a.  Random  Maintenance  Labor 

3 

OTPYX/V^  \ 

where 

CRML  = random  maintenance  labor  cost 

OTPYX  = average  operating  time  per  equipment  per  year 
(including  checkout) 

XTBM  = system  mean  time  between  random  maintenance  actions 

XKj  = percent  of  system  failures  requiring  labor  at  organization, 
intermediate,  and  depot  levels 

AMHMAj=  average  repair  time,  in  manhours,  per  maintenance 
action  for  organizational,  intermediate,  and 
depot  level  repairs 

XRj  = labor  rate  per  manhour  for  organizational,  intermediate, 
and  depot  maintenance  levels. 
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b.  Random  Maintenance  Material 


OTPYX  \ 

^ XKKi  • CMARAij 

where 

CRMM  = random  maintenance  material  cost 

OTPYX  = average  operating  time  per  equipment  per  year  (including 
checkout) 

XTBF  = system  mean  time  between  random  failures 

XKKi  = percent  of  system  failures  requiring  material  at 

organizational,  intermediate,  and  depot  levels  of  repair 

CMARAi  = average  material  cost  per  random  maintenance  repair 
action  at  organizational,  intermediate  and 
depot  levels 

c.  Random  Maintenance  Documentation  Cost 


CRMD  = 


OTPYX 

XTBM 


• CAMD 


where 

CRMD  = random  maintenance  documentation  cost 

OTPYX  = average  operating  time  per  equipment  per  year  (including 
checkout) 

XTBM  = system  mean  time  between  random  maintenance  actions 

CAMD  - average  cost  of  maintenance  documentation  per  maintenance 
action. 

d.  Random  Maintenance  Packaging  and  Transportation  Cost 
OTPYX 

CRMPAT  = • XK+(WASID  • ANMID  • CPPPMT  + CPPFI  • WASID) 

where 

CRMPAT  = random  maintenance  packaging  and  transportation  costs 

OTPYX  = average  operating  time  per  system  per  year  (including 
checkout) 

XK3  = percent  of  system  failures  requiring  labor  at  depot 
repair 

WASID  = average  shipping  weight  for  depot  level  repairable 
items 


(F-16) 


(F-)7) 


(F-18) 


179 


C’PMM  = preventive  maintenanee  material  cost 

m = number  of  different  scheduled  maintenance  actions 

O I’PYj  = operating  time  per  year  for  \th  scheduled 
maintenance  item 

P.Mlj  = sclieduled  maintenance  interval  for  jr//  item 
CMPj  = material  cost  per  scheduled  maintenance  item  j. 

Prevemive  Mainienaiice  Documentation  Cost 

III 

OTPY 


CPMD  = 


j=i 


PMlj 


CAMD 


where 

CPMD  = preventative  maintenance  documentation  cost 

m = number  of  different  scheduled  maintenance  actions 

OTPYj  = operating  time  per  year  for  jtli  schedided 
maintenance  item 

PMlj  = scheduled  maintenance  interval  for  jrh  item 

CAMD  = average  cost  of  maintenance  documentation  per 
maintenance  action. 

d.  Preventive  Maintenance  Packaging  and  Transportation  Cost 


where 


nn 

EOTPYi 

J (WASIDP:  • ANMID  • CPPPMT  + CPPPl,  • WASIDPD  (F-23) 
PMlj  ' ' ' 


j=  1 


CPMPAT  = preventive  maintenance  packaging  and  transportation 
cost 

nn  = number  of  different  scheduled  maintenance  items  required 
at  depot 

OTP^  = operating  time  per  year  for  jr/i  scheduled 
maintenance  item 

PMIj  = scheduled  maintenance  interval  for  jth  item 

WASIDPj  = shipping  weiglit  of  jtfi  scheduled  maintenance 
item 

ANMID  = average  two-way  distance  from  intermediate  level  to 
depot 
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CPPPMT  = cost  per  equipment  per  pound  per  mile  for  transportation 
for  repairable  items 

CPPPIj  = packaging  cost  per  j//i  scheduled  maintenance 
item. 


e.  Preventive  Maintenance  Cost 


CPM  = CPML  + CPMM  + CPMD  + CPMPAT 


where 


CPM 

CPML 

CPMM 

CPMD 

CPMPAT 


preventive 

preventive 

preventive 

preventive 

preventive 

cost. 


maintenance  cost 
maintenance  labor  cost 
maintenance  material  cost 
maintenance  documentation  cost 
maintenance  packaging  and  transportation 


3.  Scheduled/Unscheduled  Maintenance  Cost 

CM  = CRM  + CPM 


(F-24) 


(F-25) 


where 

CM  = scheduled/unscheduled  maintenance  cost 
CRM  = random  (unscheduled)  maintenance  cost 

CPM  = preventive  (scheduled)  maintenance  cost. 

B.  CONDEMNATION  COST 

The  condemnation  cost  results  from  attrition  or  loss  of  equipment  by  any  of  a number  of 
reasons.  The  equation  for  condemnation  cost  is 

CCON  = XK7  (CUNITP  + CUNITS)  (F-26) 


where 

CCON  = condemnation  cost 

XK7  = percent  of  equivalent  equipments  condemned  through 
attrition  per  year 

CUNITP  = prime  equipment  hardware  unit  cost 
CUNITS  = prime  equipment  software  unit  cost. 

C.  CHECKOUT  COST 

The  checkout  cost  is  the  cost  associated  with  checkout  of  the  equipment.  The  equation  for 
checkout  cost  is 
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CCO  = XHCEM  • 12  • XRl 


(F-27) 


where 

CCO  = checkout  cost 

XHCEM  = manhours  of  checkout  time  per  equipment  per  month 
XRl  = labor  rate  per  man  at  flight-line. 

D.  ENERGY  CONSUMPTION  COST 

The  energy  consumption  cost  is  given  by 


CEC  = 


OTPYX  • EDC 
EOL 


• CEPOH 


whc. 

CEC  = energy  consumption  cost 

OTPYX  = average  operating  time  per  system  per  year  (including 
checkout) 

EDC  = equipment  duty  cycle 
EOL  = equipment  operating  life 
CEPOH  = cost  of  energy  per  operating  interval. 


E.  SUPPLY  MANAGEMENT  COST 


The  cost  of  maintaining  and  supplying  logistical  management  support  is  given  by 
CSM  = XLIM  (CLIM  + XMSTSX  • CLSFSA) 


where 

CSM  = cost  of  supply  management 
XLIM  = total  number  of  line  items  managed 

CLIM  = annual  central  administration  cost  of  supply  management 
per  line  item 

XMSTSX  = number  of  different  intermediate  and  depot  maintenance 
sites 

CLSFSA  = cost  per  line  item  per  site  per  year  for  field  supply 
administration. 

F.  ANNUAL  MAINTENANCE  FACILITY  SPACE  COST 

The  annual  maintenance  facility  space  cost  is  given  by 
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(F-28) 


(F-29) 


CRFS  = XMSTSX  • FSPSA  • CAFS 


(F-30) 


when; 

C’RFS  = annual  maintenance  facility  space  cost 

XMSTSX  = number  of  different  intermediate  and  depot  maintenance 
sites 

FSPSA  = average  square  feet  of  floor  space  per  maintenance  site 
devoted  to  this  equipment 

CAFS  = average  cost  of  space  per  square  foot  per  year. 

G.  ANNUAL  RECURRING  TRAINING  COST 

The  annual  recurring  or  replacement  training  cost  for  base  and  depot  maintenance  personnel 
is  given  by 

CRT  = XNMTB  • XATB  • CRTCB  + XNMTD  • XATD  • CTRCD  (F-31) 

where 

CRT  = cost  of  annual  replacement  training 

XNMTB  = total  number  of  base  maintenance  personnel  supporting 
this  equipment 

XATB  = base  maintenance  personnel  turnover  rate  per  year 

CRTCB  = recurring  training  course  cost  per  student  per  year 

XNMTD  = total  number  of  depot  maintenance  personnel  supporting 
this  equipment 

XATD  = depot  maintenance  personnel  turnover  rate  per  year 
CRTCD  = recurring  training  course  cost  per  student  per  year. 

H.  ANNUAL  RECURRING  TECHNICAL  DATA  MANAGEMENT  COST 

The  annual  recurring  technical  data  management  cost  is  given  by 

CRTDM  = XPMT  • CPPTDM  (F-32) 


where 

CRTDM  = cost  of  annual  recurring  technical  data  management 

XPMT  = total  number  of  unique  technical  data  pages  required  for 
equipment  support 

CPPPMT  = cost  of  technical  data  management  per  page  per  year. 
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I.  ANNUAL  RECURRING  SUPPORT  EQUIPMENT  MAINTENANCE  COST 


The  annual  recurring  support  equipment  maintenance  cost  is  given  by 
CSEM  = KStXOSOi  • CMTO,  + XISO,  • CMTI,  + XDSO,  • 


where 


CSEM  = annual  recurring  support  equipment  maintenance  cost 

K8  = support  equipment  maintenance  rate  per  year  expressed  as  a 
percentage  of  unit  cost 

XOSOi  = total  number  of  organizational  level  AGE  sets 
CNlTOi  = unit  cost  of  organizational  level  AGE  sets 
XlSOi  = total  number  of  intermediate  level  AGE  sets 
CNITIi  = unit  cost  of  intermediate  level  AGE  sets 
XDSOi  = total  number  of  depot  level  AGE  sets 
CNlTDi  = unit  cost  of  depot  level  AGE  sets 


J.  SOFTWARE  MAINTENANCE  COST 

The  software  maintenance  cost  (CSWM)  is  not  set  forth  in  a mathematicai  model,  but  is  an 
engineering  estimated  value. 

K.  SUSTAINING  COST  SUMMARY 


The  sustaining  cost  is  given  by  summing  up  the  following. 


CSUS,  = CNP,  (CM  + CCON  + CCO  + CEO  + CSM  + CRFS  + CRT 
+ CKl  DM  + CSEM  + CSWM 


where 


CSUSj  = annual  sustaining  cost  in  it/i  year 
CNPj  = number  of  operating  systems  in  the  ith  year 
CM  = scheduled  and  unscheduled  maintenance  cost 
CCON  = condemnation  cost 
CCO  = checkout  cost 
CEC  = energy  consumption  cost 
CSM  = annual  supply  maintenance  cost 
CRFS  = annual  facility  space  cost 
CRT  = annual  recurring  training  cost 


(104) 
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CR  I DM  = annual  technical  data  management  cost 
I'SI  M = annual  support  equipment  maintenance  cost 
C'SWM  = annual  software  maintenance  cost. 

IV.  LIFE  CYCLE  COST  OR  CUMULATIVE  COST  OF  OWNERSHIP 

The  life  cycle  cost  (LCC)  or  cumulative  cost  of  ownership  (COTOT)  is  given  by  the 
following  ei|uation. 

t 

L(T  - COTOT  = ^ (CACOi  + CSUSj)  (F-35) 

i=  I 

where 

LCC  = life-cycle  cost  at  the  end  of  T years 

CACQj  = acquisition  cost  during  the  \th  year 

CSUSj  = sustaining  cost  during  the  ith  year 

t = years  of  equipment  in  the  inventory  (t  = T for  the  last 
program  year). 
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APPENDIX  G 

LCC  ANALYSIS  DATA  AND  DATA  SOURCES 


APPENDIX  G 

LCC  ANALYSIS  DATA  AND  DATA  SOURCES 


The  data  contained  in  this  appendix  was  used  in  the  LCC  analysis  in  Section  IV  of  this 
report.  This  data  resulted  from  cost  estimates  and  analysis  techniques  employed  by  Texas 
Instruments  engineering,  logistical,  training,  technical  publications,  reliability,  maintainability,  and 
logistical  support  staffs.  In  some  instances,  data  was  acquired  from  the  Air  Force  and  other 
sources.  Such  data  includes  details  of  the  ARPV  operational  scenario,  AFLC  logistical  support 
cost  model,  and  AFLC  standard  cost  factors. 


APPENDIX  G.  LCC  ANALYSIS  DATA  AND  DATA  SOURCES 
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XOSj,  XOSOj  3,0,0,0,0,0,0,0,0,0  3. 0,0 ,0,0 ,0,0 ,0,0,0  3,0,0,0,0,0,0,0,0,0  USAF  Estimate 

CNITOj  $8,850,0  . . .,0  $8,850,0,  . . .,0  $8,850,0  . . .,0  Engineering  Estimate 

CISTOj  $1,770,0,0,  ...  ,0  $1,770,0,0 0 $1,770,0,0 0 20%  of  Unit  Cost 

Estimate 


Value  for 

Parameter  Strike-Centralized  Strike-Hybrid  Strike-DP/M 


Parameter  Strike-Centralized  Strike-Hybrid  Strike-DP/M 


